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ABSTRACT 


Submarines  offer  a  capability  to  deploy  and  retrieve  unmanned  undersea  vehicles 
(UUV)  in  littoral  and  blue  water  Areas  of  Operation  while  avoiding  detection. 

Integration  of  the  submarine  and  UUV  through  a  launch  and  recovery  mechanism  offers 
unique  challenges  with  respect  to  host  submarine  safety,  UUV  recovery,  UUV 
replenishment  and  life-cycle  costs.  The  Capstone  team  elicited  launch  and  recovery 
system  requirements  from  stakeholders  and  conceived  four  (4)  advanced  alternatives  and 
a  baseline  alternative  considered  to  meet  the  requirements.  Through  functional,  cost, 
risk,  modeling  and  qualitative  analysis,  this  study  assessed  the  value  of  each  alternative  to 
stakeholders.  Of  the  concept  alternatives  explored,  a  high  tech  option  featuring  a  carbon 
fiber  structure,  electro-mechanical  pulse  launch  and  recovery  device  and  proximity  vice 
contact  battery  charging  and  UUV  stowage  features  provided  the  best  value  to  the 
stakeholders  for  the  investment.  These  results  highlighted  characteristics,  including 
maintenance  considerations,  upgradeability,  design  for  reliability  and  design  for  universal 
applications  considered  paramount  for  a  successful  system.  Project  lessons  learned 
uncovered  significant  risk  due  to  instability  of  UUV  requirements  as  well  as  certification 
issues  which  adversely  affect  a  submarine/UUV  integration  project.  Early 
communications  between  key  stakeholders  must  effectively  address  these  short-comings. 
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EXECUTIVE  SUMMARY 


This  Capstone  project  focused  on  the  considerations  and  interfaces  needed  to 
successfully  field  and  support  a  system  that  would  launch,  recover,  replenish,  stow  and 
transfer  information  between  current  and  future  Large  Vehicle  Class  Unmanned 
Undersea  Vehicles  (UUVs)  and  host  submarines,  specifically  submarines  with  the  VA 
Class  Block  III  payload  tube  concept.  This  system  will  provide  a  capability  to  support 
persistent-ISR  missions  identified  in  the  UUV  Master  Plan  of  2004  by  providing  stealthy 
information  collection  capabilities,  threat  and  harbor  monitoring,  WMD  identification 
and  sea  floor  object  reconnaissance. 

To  accomplish  the  project  objectives,  the  Capstone  team  used  a  Systems 
Engineering  approach  to  analyze  and  develop  system  requirements  and  functions  which 
led  to  the  establishment  of  five  (5)  proposed  concept  alternatives.  These  alternatives 
were  compared  and  contrasted  with  respect  to  perfonnance,  life-cycle  costs,  risks  and 
suitability  through  modeling  and  simulation,  direct  cost  analysis  and  qualitative  analysis. 

Of  the  concept  alternatives  explored,  Alternative  4  (a  high  tech  option  featuring  a 
carbon  fiber  structure,  electro-mechanical  pulse  launch  and  recovery  device  and 
proximity  vice  contact  battery  charging  and  UUV  stowage  features)  provided  the  best 
value  to  the  stakeholders  for  the  investment.  Alternative  4  demonstrated  superior  model 
perfonnance  times  with  an  acceptable  rate  of  success.  Acquisition  costs  were  mid-range 
while  sustainment  costs  were  comparatively  low  due  to  high  reliability  and 
maintainability  of  the  structure,  redundant  features  and  lack  of  frictional  wear  issues. 

Specific  technologies  for  concept  component  packages  and  the  pros  and  cons  for 

the  technologies  were  based  on  Capstone  team  experience,  discussions  with  peer-groups 
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and  available  literature.  Future  technologies  may  result  in  alternative  groupings  that 
provide  superior  value  to  the  stakeholder  at  equal  or  less  investment.  However,  the 
Capstone  team  concluded  that  several  characteristics,  detailed  below,  are  keys  to  any 
successful  system: 

•  Structural  components  are  the  most  significant  cost  driver,  both  in  acquisition 
and  maintenance.  Solutions  should  consider  mixed  materials  such  as  molding 
metallic  parts  into  the  composites  at  manufacture  to  increase  strength  at 
component  attachment  points  while  still  providing  a  light-weight,  corrosion- 
resistant  and  cost-stable  structure  that  is  upgradeable  without  extensive  re¬ 
fabrication. 

•  Successful  launch  and  recovery  mechanisms  must  be  adaptive  to  UUV  size, 
shapes  and  materials  and  must  minimize  submarine  dwell  time.  Mechanisms 
should  consider  ways  to  attract  or  repel  the  UUV  without  physical  contact. 

•  Technology  packages  should  focus  on  systems  that  multi-task  and  adequately 
function  in  the  event  of  minor  failures.  Components  that  offer  redundant 
functions  and  fault-tolerance  increase  overall  reliability. 

The  Capstone  team  identified  several  lessons  learned  for  consideration  which  may 
enhance  follow-on  UUV/submarine  integration  projects  and  studies: 

•  Requirements  Stability  -  Stakeholders  should  consider  re-visiting  the 
mission  and  operational  parameters  established  for  persistent  -ISR  operations 
in  the  2004  UUV  Master  Plan.  Particular  emphasis  should  be  focused  on 
endurance  requirements  for  perceived  missions  and  whether  it  is  feasible,  in 
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the  near  tenn,  to  field  UUVs  that  meet  those  endurance  requirements  and 
enable  submarines  to  support  those  endurance  requirements. 

•  Submarine/UUV  System  Certification  Issues  -  Due  to  operational 
environment  and  contained  structure,  UUVs  and  their  launch/recovery 
mechanisms  can  pose  a  widespread  and  detrimental  effect  to  the  host 
submarine  and  submarine  personnel  not  seen  with  air  or  ground  unmanned 
vehicles.  While  governing  ASTM  guides  provide  guidelines  for  the 
capabilities  of  UUVs,  they  do  not  specifically  address  constraints  related  to 
submarine  launch  and  recovery  platforms.  Integration  issues,  particularly 
those  related  to  Submarine  Safety  (SUB  SAFE)  require  early  and  on-going 
teaming  between  submarine  and  UUV  stakeholders. 

•  Modularity/Flexibility  -  UUV  manufacturers  continue  exploration  of 
technologies  meant  to  break  through  constraints  that  limit  current  capabilities. 
As  newer  technologies  affect  UUV  size,  materials  and  capabilities,  early  and 
close  relationships  with  UUV  designers  is  paramount  to  ensure  launch  and 
recovery  system  functions  support  UUV  design  trends. 
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I.  INTRODUCTION 

A.  PROBLEM  STATEMENT 

1.  Background 

Submarines  provide  the  Navy  the  ability  to  deliver  effects  or  conduct  operations  without 
adversary  warning  or  detection.  However,  due  to  many  factors  including  draft,  size,  and 
personnel  considerations,  submarines  do  not  operate  on  station  for  deployments  longer  than 
about  90  days  and,  in  particular,  cannot  operate  in  littoral  waters  off  an  adversary’s  coastline. 
Submarine  launched  Unmanned  Undersea  Vehicles  (UUVs)  can  help  conduct  missions  and 
reduce  the  risk  to  manned  platforms,  while  increasing  the  range  and  endurance  of  a  mission. 

In  2009,  the  Chief  of  Naval  Operations  (CNO)  directed  his  staff  to  develop  unmanned 
system  plans  for  near-term  (5  years)  and  mid-term  (10  year)  timeframes,  as  well  as  a  30-year 
vision.  In  parallel  with  the  CNO  staff  planning  efforts,  the  Director  of  Undersea  Technology, 
SEA073,  initiated  a  study,  published  as  the  UUV  Roadmap,  to  coordinate  Navy-wide  UUV 
efforts  and  develop  a  plan  for  UUV  operations  from  a  variety  of  platfonns.  The  2004  UUV 
Master  Plan  documented  a  vision  for  unmanned  undersea  vehicles  (Figure  1)  and  determined  that 
Intelligence,  Surveillance  and  Reconnaissance  (ISR)  operations  was  the  most  important  mission 
for  UUV  military  applications.  Persistent-ISR  capabilities  support  the  “Sea  Power  21”  Pillars 
by  providing  stealthy  infonnation  collection  capabilities,  threat  and  harbor  monitoring,  WMD 
identification  and  sea  floor  object  reconnaissance  (Figure  2).  Large  Vehicle  Class  UUVs, 
defined  as  multi-platform  compatible  vehicles,  which  displace  approximately  10  long  tons  and 
are  typically  over  21  inches  in  diameter,  is  one  type  of  UUV  identified  to  support  ISR  missions. 
The  Large  Vehicle  Class  UUVs  that  support  ISR  operations  generally  have  an  on  station  time  of 
at  least  300  hours  and  a  mission  range  of  at  least  75  nautical  miles  [UUV  Master  Plan  2004]. 
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The  increased  size  inherently  provides  Large  Vehicle  Class  UUVs  payload,  power  and 
endurance  advantages  over  smaller  UUVs. 
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UUVMP  Vision... 


.attack  today’s  littoral  coverage  problem 
and  tomorrow’s  advanced  threat 


Broad  area  denial  is  a  real  threat  given  technology  trends.  Undersea  systems  may  be  the  only  “undenied” 
force  early.  Unmanned  Undersea  Vehicles  provide  the  Force  Multiplication  needed  to  gain  access  early. 


Figure  1  -  UUV  Master  Plan  Vision  [UUV  Master  Plan,  2004] 
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Figure  2  -  ISR  UUV  Sub  Pillar  [UUV  Master  Plan,  2004] 

2.  Need  Statement 

Launching  of  UUVs  from  submarines  has  been  accomplished  using  the  host  platfonn’s 
21 -inch  diameter  torpedo  tubes.  The  conversion  of  four  ballistic  missile  (SSBN)  submarines  to 
guided  missile  submarines  (SSGN)  resulted  in  an  added  capability  of  launching  and  interfacing 
with  larger  diameter  UUVs  by  utilizing  the  SSGN’s  88-inch  tactical  payload  tubes.  Beginning 
with  the  construction  of  Virginia  (VA)  Class  Block  III  fast-attack  nuclear  submarines  (SSNs 
784-791),  this  submarine  class  will  be  equipped  with  2  SSGN-like  payload  tubes  rather  than  the 
12  smaller  vertical  launch  tubes  found  on  Block  I  and  II  VA  Class  submarine  designs.  This 
gives  the  Block  III  and  later  increments  of  the  submarine  class  the  ability  to  launch  and  interface 
with  Large  Vehicle  Class  UUVs.  For  submarine  launched  Large  Vehicle  Class  UUVs  to  be  an 
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effective  tool  for  undersea  warfare  persistent-ISR  operations,  a  system  is  required  to  integrate  the 
host  submarine  and  the  Large  Vehicle  Class  UUVs.  This  system  must  provide  launch,  recovery, 
replenishment  and  communication  capabilities  without  adversely  affecting  the  certification  of  the 
host  submarine  for  unrestricted  operations. 

3 .  Pr o j  ect  Ob j  ective 

Using  System  Engineering  principles  and  following  the  guidance  established  in  the 
Project  Management  Plan  (Appendix  A),  the  Capstone  team  developed  the  concepts  and 
functions  necessary  and  offered  a  conceptual  preliminary  design  of  a  system  that  integrates  the 
Large  Vehicle  Class  UUVs  with  the  VA  Class  Block  III  Submarine  payload  tube  concept.  The 
analysis  focused  on  a  family  of  systems  (FOS)  and  their  interfaces  that  supports  launch, 
recovery,  replenishment,  communication  with  and  stowage  of  a  Large  Vehicle  Class  UUV  on  a 
submarine  with  a  VA  Class  Block  III  payload  tube  concept. 

B.  ASSUMPTIONS 

This  project  sought  to  identify  the  functionality  (and  the  physical  architecture  needed  to 
accomplish  the  functionality)  of  a  standard  launch,  recovery  and  communication  mechanism  that 
integrates  with  the  external  boundaries  of  the  submarine  launched  Large  Vehicle  Class  UUV  and 
a  host  submarine  which  employs  the  VA  Class  Block  III  payload  tube  concept.  Through  analysis 
of  the  requirements,  mission,  functions,  components  and  interfaces,  the  scope  of  this  project  was 
to  identify  the  concepts  necessary  to  define  the  interactions  between  the  UUV  and  the  host 
submarine.  The  Capstone  team  developed  several  key  assumptions  to  establish  the  guidelines 
and  boundaries  of  this  research  project: 

•  The  Capstone  team  recognized  that  design  and  development  of  UUV  systems  is  a 
rapid  and  dynamic  environment  and,  due  to  the  classified  nature  of  future  threat 
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planning  and  assessment,  only  general  missions,  threats  and  scenarios  were 
realistically  and  reasonably  assessed.  Additionally,  it  was  considered  acceptable  that 
this  project  not  decompose  system  functions  and  physical  architecture  into  detailed 
designs  where  specific  interactions  between  human  operators,  submarine 
communication  systems  and  UUV  control  systems  became  classification  sensitive. 

•  For  the  starting  point  of  design  and  capability  research,  this  project  leveraged  off  of 
existing  and  similar  concepts  for  a  Large  Vehicle  Class  UUV  launched  and  recovered 
via  torpedo  tubes  (Figure  3)  and  a  SSGN  large  missile  tube  launch  and  recovery 
system  (Figure  4).  This  project  sought  to  improve  upon  these  concepts. 

•  The  main  challenges  of  the  project  remained  what  they  are  for  existing  systems; 
namely  power  needs  for  replenishment  of  Large  Vehicle  Class  UUVs,  difficulties 
encountered  with  UUV  recovery,  impacts  on  host  submarine  safety  and  system 
operational  parameters,  which  limit  the  effectiveness  of  existing  concepts. 

•  The  system-engineering  approach  employed  on  this  project  captured  and  verified  the 
many  divergent  stakeholder  needs  associated  with  fielding  of  future  UUV  launch  and 
recovery  concepts  and  will  provided  a  basis  for  examination  and  analysis  of  future 
UUV/host  submarine  integrated  concepts  with  a  concentration  on  performance  and 
total  ownership  costs. 

•  To  establish  the  “fixed”  external  boundaries  necessary  for  interface,  cost, 
perfonnance  and  design  examination,  this  project  was  specific  for  integration  of  a 
“standard”  Large  Vehicle  Class  UUV  with  VA  Class  Block  III  and  later  submarines 
only.  This  project  did  not  examine  Large  Vehicle  Class  UUV  integration  with  any 
other  class  of  submarine.  However,  it  is  expected  the  results  and  conclusions  of  this 
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project  would  apply  to  any  US  Navy  or  foreign  submarine  which  exhibits 
dimensional  and  functional  characteristics  similar  to  the  VA  Class  Block  III 
submarine  payload  tube  concept. 


Figure  3  -  AN/BLQ-11  Long-Term  Mine  Reconnaissance  System  (LMRS)  (Torpedo  Tube 
Launch  and  Recovery  System)  [White,  D.  P.,  2007] 


Docking  Cone - 

Launch  &  Recover  Cradle - 


Extending  Mast 


Data  Link  to  SSGN 

Hydraulic  Power  Unit 
L&R  Control  Unit  - 


GENERAL  DYNAMICS 

Electric  Boat 

UNCLASSIFIED 


Figure  4  -  Universal  Launch  and  Recovery  Module  (ULRM)  (SSGN  Missile  Tube  Launch 

and  Recovery  System)  [White,  D.  P.,  2007] 


6 


C.  SYSTEM  ENGINEERING  APPROACH 


1.  Overview 

The  Capstone  team  focused  on  the  identification  of  and  verification  of  stakeholder  needs 
while  applying  a  Systems  Engineering  approach  in  a  phased  plan  strategy.  To  this  end,  the  team 
delivered  a  System  Engineering  solution  to  satisfy  the  current  need  of  the  stakeholders  seeking  to 
launch,  recover,  communicate  with,  replenish  and  stow  Large  Vehicle  Class  UUVs  with 
submarine  host  platfonns,  specifically  the  VA  Class  Block  III  submarine.  The  topics  addressed 
herein  outline  the  approach  and  structure  to  successfully  define  system  requirements, 
functionality,  synthesis  and  design.  To  mitigate  risks  and  maximize  stakeholder  satisfaction,  the 
active  stakeholders  and  Subject  Matter  Experts  (SME)  were  involved  throughout  the  engineering 
process. 

a.  Systems  Engineering  Process  Model 

The  Capstone  team  utilized  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
System  Engineering  Process  Model,  Figure  5,  to  identify  the  stakeholder  needs  and  deliver  the 
best  recommended  solutions.  The  IEEE  System  Engineering  Process  Model  has  six  process 
phases. 
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Figure  5  -  IEEE  System  Engineering  Process  Model  [IEEE  Standard  1220, 1998] 
2.  Systems  Engineering  Process  Phases 

The  process  phases,  shown  in  the  IEEE  System  Engineering  Process  Model,  Figure  5, 
and  actions  taken  to  accomplish  the  phases  of  the  process  model,  are  detailed  as  follows: 

a.  Requirements  Analysis  Phase 

Input:  Stakeholder  needs 

Output:  Requirements  baseline 

Actions:  Define  Needs,  Define  Risks,  Manage  Requirements,  Prioritize  System 

Design,  Assess  and  Trade-Off  Requirements 

The  stakeholder  needs  were  used  to  identify  design  requirements  and  prioritize  system 
capabilities.  During  the  stakeholder  needs  analysis,  the  stated  need  requirements  were  base 
lined. 
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System  risks  were  identified  throughout  the  development  of  the  design  process.  Risk 
mitigation  strategies  were  used  throughout  the  process  to  avoid  and  manage  the  risks  associated 
with  the  development  of  the  system.  System  requirements  were  generated  with  the  continuous 
involvement  of  stakeholders  throughout  all  phases  of  the  project.  This  supported  requirement 
management  and  reduced  the  risk  of  misinterpreting  the  stakeholder  needs,  values  and  priorities. 
With  the  involvement  of  the  identified  stakeholders,  system  design  capabilities  and  perfonnance 
requirements  were  prioritized  with  the  use  of  various  system  metrics  and  traced  to  their  needs. 
The  scaled  level  of  priority  supported  future  trade-off  analysis  when  evaluating  alternative 
solutions.  Requirement  trade-off  analysis  was  performed  to  resolve  conflicts,  including  funding, 
schedule,  perfonnance  and  quality  needs.  Risk  levels  and  mitigations  were  used  throughout  the 
requirement  trade-off  analysis.  The  ultimate  deliverable  was  a  final  assessment  of  system 
requirements  that  governed  the  design  of  the  Large  Vehicle  Class  UUV  interface  to  the  host 
submarine. 

b.  Requirements  Verification  Phase 

Input:  List  of  requirements  for  stakeholder  verification 

Output:  Validated  requirements  baseline 

Actions:  Define  System  Functions,  Conduct  Functional  Traceability,  Validate 

Functions  to  Requirements 

The  establishment  of  the  requirements  baseline  was  followed  by  the  functional  analysis, 
which  established  the  functional  architecture  and  validated  the  requirements  baseline.  The 
requirements  baseline  was  analyzed,  and  from  the  baseline,  the  top  level  functions  were 
identified  and  the  functional  decomposition  was  perfonned  with  enough  granularity  such  that  the 
end  state  of  each  decomposition  contains  the  backbone  (and  vertebrae)  of  each  of  the  top  level 
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functions.  The  functions  that  were  not  directly  concerned  with  the  engineering  aspects  of  the 
project  were  decomposed  to  lesser  degrees  of  granularity  due  to  the  focus/bulk  of  the  work 
needing  proper  definition  in  the  engineering  realm.  A  functional  hierarchy  of  system 
requirements  was  drafted  so  requirements  were  traceable  to  the  particular  stakeholder  need. 
Infonnation  flow  block  diagrams  were  established  and  functions  were  allocated  to  system 
components  and  perfonners. 

c.  Functional  Analysis  Phase 

Input:  Validated  requirements  baseline 

Output:  Functional  needs  and  requirements 

Actions:  Create  Alternative  Design  Concepts,  Examine  Feasibility,  Score 

Alternative  Design  Concepts,  Conduct  Cost-Benefit  Analysis,  Conduct  Functional  Trade  Studies 
&  Assessments 

Alternative  design  concepts  were  created  using  the  base  lined  requirements  proposed  by 
the  stakeholders.  The  team  members  prioritized  system  capabilities  so  that  critical  functions  and 
their  sub-functions  supported  the  system’s  mission.  Quality  Functional  Deployment  (QFD) 
models  with  weighted  values  were  used  to  assess  the  proposed  alternative  design  solutions  and 
establish  component  concepts  that  could  perfonn  the  required  functions.  The  alternative  designs 
were  evaluated  for  design  feasibility  with  regard  to  budget,  acceptable  risk  and  schedule. 
Feasibility  criteria  defined  by  the  stakeholders  and  team  members  were  used  to  screen  all 
alternative  design  concepts.  Failure  to  satisfy  the  feasibility  criteria  would  deem  the  concept  to 
be  infeasible  and,  as  such,  the  alternative  was  discarded  to  reduce  strain  on  the  project’s 
resources,  so  that  time  and  value  assets  were  not  wasted.  The  team  used  metrics  to  score 
concept  design  alternatives.  The  active  stakeholders  participated  with  the  team  to  verify  and 
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validate  that  the  final  conceptual  alternatives  satisfied  the  needs  at  an  acceptable  level  of  risk. 
Any  requirement  conflict  observed  was  addressed  and  adjudicated  with  the  involvement  of 
stakeholders. 

A  cost-benefit  analysis  was  performed  to  formally  identify  and  assess  benefits  associated 
with  design  alternatives  in  addition  to  the  costs  anticipated  from  the  project.  The  cost  analysis 
evaluated  the  value  associated  with  the  system  over  its  life  cycle  in  relation  to  its  stakeholder 
benefit.  The  cost-benefit  analysis  was  one  of  the  factors  that  resulted  in  a  recommended  design 
for  prototyping  that  offered  the  greatest  value  to  the  stakeholders  while  meeting  all  design  Key 
Perfonnance  Parameter  (KPP)  and  schedule  requirements.  Once  the  functional  analysis  was 
accomplished,  the  functional  trade  studies  and  assessments  of  the  top  level  functions  and  their 
decomposition  were  conducted.  The  analysis  looked  at  tradeoffs  for  identified  functions  and 
evaluated  related  functions  that  may  not  have  been  originally  identified  to  see  if  they  were  useful 
or  necessary  for  the  efficient  completion  of  the  project  (e.g.  is  anything  missing  from  the 
functions?  Could  there  be  an  alternate  function  that  provides  a  better  solution?  Have  the 
engineering  functions  been  decomposed  such  that  their  bottom  level  provides  the  building  blocks 
to  meet  the  stakeholder  needs  with  the  top  level  function?).  The  results  of  the  trade-offs  were 
analyzed  and  the  best  solution  was  worked  into  the  final  functional  decomposition, 
d.  Functional  Verification  Phase 

Input:  Functional  Needs 

Output:  Verified  Functional  Needs  and  Concepts 

Actions:  Conduct  Life-Cycle  Cost  Analysis,  Conduct  Model  Simulations,  Conduct 

Sensitivity  Analysis,  Analyze  Performance  and  Costs  of  Concepts 
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From  the  functional  needs/requirements,  the  functional  verification  took  place.  This 
analyzed  the  top  level  functions  and  their  decomposition  to  make  sure  that  the  chosen 
architecture  met  all  stakeholder  requirements.  Modeling  was  utilized  to  simulate  the  Operational 
Situations  (OPSITs)  which  defined  the  theater  of  operation  and  mission  requirements. 

Simulation  results  provided  the  team  with  critical  information  pertaining  to  system  perfonnance 
and  operation.  Aspects  such  as,  but  not  limited  to,  operational  availability,  successful  launch, 
successful  recovery,  system  causality,  communication  failure  and  other  potential  risks  were 
analyzed  to  evaluate  the  capability  of  alternative  designs.  Results  were  utilized  to  weigh  design 
selection.  A  sensitivity  analysis  was  performed  to  evaluate  the  system  design  parameters 
relationships  and  the  results  of  the  baseline  analysis  to  ensure  that  the  overall  life-cycle  costs  and 
model  generated  were  valid.  Critical  input  parameters  were  identified  that  directly  impact  cost 
(more  than  10%  of  total  cost).  The  identified  critical  input  parameters  were  evaluated  in  a  model 
to  simulate  the  cost  impact  associated  with  the  model’s  output.  Critical  input  parameter 
variations  were  modeled  over  a  designated  range  which  considered  appropriate  distributions  for 
the  system  design  critical  items.  It  was  essential  for  the  analyst  to  be  confident  with  the 
identified  critical  inputs  interrelationships,  their  impact  on  cost,  the  sensitivities  of  the  model  in 
the  identification  of  cause-and-effect  relationships  and  the  potential  areas  of  risk  associated  with 
the  Life-Cycle  Costs  (LCC)  analysis  results.  The  analysis  resulted  in  the  sensitivity  of  a  system’s 
LCC  in  relation  to  potential  variations  such  as  but  not  limited  to  operational  availability,  mean 
time  between  maintenance,  and  system  casualties. 
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e.  Synthesis  Phase 

Input:  Verified  Functional  Architecture 

Output:  Physical  Architecture 

Actions:  Initiate  Design  Process,  Conduct  Design  Trade  Studies  &  Assessments 

Once  the  functional  need  and  requirements  were  verified,  the  design  process  began  to 
establish  the  physical  architecture.  Here,  the  interface  documents  were  developed  as  well  as  the 
specifications  for  the  hardware  and  software.  Utilizing  the  developed  interface  documents,  the 
hardware  and  software  design  and  development  would  progress.  Hardware  and  software 
components  were  researched  and  conceived  to  conceptual,  performance  and  interface  standpoint. 
From  the  physical  architecture,  the  last  of  the  trade-offs  were  conducted.  The  design  trade-off 
examined  the  way  the  design  was  assembled  and  explored  alternate  means  of  construction  (e.g. 
did  we  pick  the  most  efficient  way  to  integrate  the  Large  Vehicle  Class  UUV  and  the  host 
submarine?  What  is  the  relationship  between  different  combinations  of  hardware  and  reliability 
of  successful  UUV  launch/recovery?).  From  the  explored  trade  spaces,  the  most  efficient 
solution  was  put  forward  and  finalized  as  the  physical  architecture  for  the  UUV  Launch  and 
Recovery  System  (LRS). 

f.  Design  Verification  Phase 

Input:  Physical  Architecture 

Output:  Verified  Physical  Architecture 

Actions:  Accomplish  Verification,  Decision-Making  and  Conclusion  Analysis 

The  Design  Verification  phase  implemented  the  test  and  evaluation  strategy  to  make  sure 
that  the  physical  architecture  met  all  derived  and  stated  stakeholder  requirements.  The 
successfully  executed  test  plan,  based  on  the  system’s  requirements  verification  matrix  and  the 
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passing  of  all  tests  results,  verified  physical  architecture  that  was  ready  for  detailed  design  and 
eventual  production. 
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II.  REQUIREMENTS  ANALYSIS  AND  VERIFICATION 

A.  STAKEHOLDER  NEEDS  ANALYSIS 

1.  Background 

Stakeholder  needs  analysis  captured  the  functions,  attributes  and  relationships  of  the 
system  proposed  to  meet  the  perceived  capability  gap.  [Blanchard  &  Fabrycky,  2006,  pg.  57-59] 
The  results  of  needs  analysis  were  a  set  of  requirements  based  on  a  solid  foundation  of  customer 
desires  to  ultimately  create  a  system  that  not  only  functions  as  the  engineers  expected,  but  also 
accomplishes  the  goals,  either  expressed  or  implicit,  by  the  stakeholders. 

Upon  initial  review,  the  needs  for  this  project  can  seem  to  be  rather  basic;  develop  the 
systems  required  for  a  submarine  to  launch,  control  and  recover  Large  Vehicle  Class  UUVs. 
However,  such  a  system  may  endure  a  costly  and  short  life  if  it  is  simply  developed  to  the 
personal  whims,  political  pressures  or  particular  interests  of  one  or  a  few  stakeholders. 

Therefore,  the  focus  on  needs  analysis  during  this  project  was  to  examine  as  many  credible 
sources  as  possible  and  develop  many  varied  and,  at  times  conflicting,  needs  from  these  sources. 
Upon  determination  of  the  functions,  attributes  and  relationships,  or  the  “wants”  required  for  the 
system,  the  team  translated  these  into  more  specific  system-level  requirements.  To  ensure  the 
team  captured  the  intent  of  the  customers,  the  system-level  requirements  were  documented  and 
verified  against  the  clear  statements  of  intent  from  interviews  and  literature.  The  outcome  of  this 
process  allowed  the  team  to  develop  a  ranked  and  weighted  list  of  Stakeholder  Requirements  for 
the  system  that  supports  not  only  immediate  needs,  but  also  potential  UUV  scenarios  in  the 
future. 


15 


2.  Methodology 

The  team  used  their  experience,  discussions  with  proxy  stakeholders  (Subject  Matter 
Experts  or  SMEs),  and  literature  research  to  determine  the  stakeholder  needs  and  value  system 
associated  with  the  needs.  These  needs  were  then  ranked  using  an  Analytic  Hierarchy  Process 
(AHP).  This  AHP  uses  pair-wise  comparisons  to  rank  the  stakeholders  needs.  Each  team 
members  used  the  information  obtained  from  the  SMEs,  along  with  the  literature  research  and 
team  member  experience  to  conduct  a  pair-wise  comparison  of  the  stakeholder  needs.  The 
average  of  the  team  member’s  pair-wise  comparisons  was  used  to  detennine  the  priorities  of  the 
needs  by  assigning  a  weighted  value  to  each  need.  These  rankings  were  used  when  determining 
the  system  perfonnance  objectives,  the  KPPs,  and  the  component  requirements  and  risks  for  the 
conceptual  design  alternatives. 

3.  Stakeholders 

There  are  two  categories  of  Stakeholders,  identified  in  Table  1,  active  and  passive. 

Active  stakeholders  directly  influence  the  requirements  development  phase  of  the  project  while 
passive  stakeholders  provide  indirect  influence  into  project  requirements  development. 

The  team  met  with  the  active  stakeholders  as  practical  and  used  feedback  from  these 
active  stakeholders  to  verify  the  conceived  system  requirements.  Their  validation  of  the 
proposed  requirements  resulted  in  the  team’s  identification  of  the  verified  requirements  baseline. 

The  passive  stakeholders  were  existing  entities  with  interests  and/or  policies  concerning 
UUVs  and  UUV  missions.  The  passive  stakeholders’  needs  were  derived  from  the  literature 
published  directly  by  stakeholders  and  their  representatives  or  literature  published  by  experts  in 
the  field.  The  literature  research  identified  several  areas  of  interest  with  respect  to  deployment, 
replenishment  and  retrieval  of  UUVs  from  submarines. 
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Safety: 


•  Past  systems  “did  not  address  Submarine  Safety  (SUBSAFE)  issues  or  field  usable 
systems.  Current  systems  Mission  Reprogrammable  Unmanned  Undersea  Vehicles 
(MRUUVs)  also  will  not  address  those  long-standing  safety  issues  and  will  not  field  a 
usable  system  by  2013.”  Additionally,  “the  development  of  (systems)  to  be  launched 
from  SSN  torpedo  tubes  is  difficult  and  requires  design  compromises.”  [Button, 

2009] 

•  “Safety  justification  is  likely  to  be  harder  if  divers  are  required  to  work  in  and  outside 
(an  external  launch,  recovery  and  stowage  mechanism).”  [Hardy,  2008] 

UUV  Recovery: 

•  “Recovery  is  arguably  more  difficult  when  the  submarine  is  in  transit.”  [Hardy,  2008] 

•  It  is  “very  unlikely  to  be  able  to  retrofit  (an  enlarged  torpedo  tube  concept)  system 
into  an  existing  submarine.”  [Hardy,  2008] 

•  Large  diameter  UUV  challenges  with  respect  to  operations  include  “Contact 
avoidance  with  high  traffic  density  including  low  signature  fishing  trawlers  and  high 
speed  vessels”  (requires  considerations  for  rapid  recovery).  [Ashton,  2010] 

UUV  Power  Challenges: 

•  “Energy  has  long  been  a  major  consideration  due  to  its  effect  on  the  ultimate 
perfonnance  of  extended  vehicle  missions.”  [Fletcher,  2005] 

•  Forward  ends  of  “SSN  submarines  lack  electrical  power  distribution  systems  needed 
to  charge  large,  battery  powered  UUV.”  [Button,  2009] 
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Concerns  for  Total  Ownership  Costs: 


•  “The  size  and  number  of  vehicles  to  be  used,  the  overall  system  costs,  and  the 
interchangeability  of  modules  all  need  to  be  considered  as  a  critical  part  in  developing 
the  needed  capabilities.”  [Fletcher,  2005] 

•  The  “technology  (of  UUVs)  has  not  lived  up  to  where  the  Navy  thought  it  was  going 
to  be  at  this  point.  If  you  want  autonomous  vehicles  underwater,  you  have  to  advance 
the  technology  further  before  it  is  really  capable  -  RADM  Hilarides,  Program 
Executive  Officer  (PEO)  Submarines”  [Fein,  2007] 

Table  1  -  Project  Stakeholders  and  Needs 


Stakeholder 

Needs 

Project  Advisors  (Active) 

Ensure  successful  completion  of  the  Capstone 
project 

Launch  and  Recovery  Mechanism  End 
Users  (Passive) 

Operating  Parameters  and  Capabilities,  Safety, 
Reliability,  Maintainable,  Stealth 

UUV  Manufacturers  (Passive) 

New  Platform  for  Equipment  -  Increased 

Market  Share,  Cost,  Long-Term  Commitment 

Host  Submarine  Force  Operators 
(Passive) 

Flexible  UUV  Missions,  Interoperable, 

Reliable,  Safety 

Naval  Intelligence  Community 
(Passive) 

Data  Transfer  Security  and  Range, 
Interoperability,  Persistent  ISR  Support 

Naval  Sea  Systems  Command  - 
(Technical  Concerns)  (Passive) 

Safety,  Reliability,  Operational  Capabilities 

Office  of  the  Chief  of  Naval  Operations 
(Passive) 

Affordability,  Flexible  UUV  Missions,  Safety, 
Perfonnance 

System  Logistics  and  Maintenance 
Suppliers  (Passive) 

Long  Term  Commitments,  Total  Ownership 
Costs,  Reliability 

Program  Offices  (Host  Sub  &  UUV) 
(Passive) 

Operational  Parameters,  Flexibility,  Support 
Multiple  Needs,  Long-Term  Commitments, 
Safety,  Total  Ownership  Costs 
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Figure  6  provides  a  hierarchical  chart,  which  illustrates  the  passive  stakeholder’s 
relationships  and  interactions.  In  Figure  6,  the  stakeholders  are  color  coded  to  reflect  Technical 


Authority  (Red),  Operational  Authority  (Green),  and  Program  Authority  (Gray). 


Figure  6  -  Hierarchal  Representation  of  Passive  Stakeholder  Relationships 

In  addition  to  the  passive  stakeholders  identified  needs,  the  team  interviewed  SMEs  with 
current  or  past  interests  in  Large  Vehicle  Class  UUV  programs.  Although  the  resultant  needs 
identified  from  some  of  these  interviews  constituted  personnel  opinions  and/or  interests  in 
specific  aspects  of  UUV  programs,  taken  as  a  whole,  these  interviews  provided  the  team 
invaluable  information  as  to  the  perception  of  programs  as  well  as  exposed  gaps  and  liabilities  in 
past  attempts  to  integrate  UUVs  and  submarines.  Table  2  provides  a  synopsis  of  the  results  from 
team  interviews  with  SMEs.  These  SME  results  were  consistent  with  the  needs  analysis  of  the 
stakeholders  developed  by  the  team  through  literature  research  and  identified  in  Table  1. 
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Table  2  -  SME  Interviewees  and  Results 


Name 

Date 

Organization 

Title 

Key  Points 

Mr.  Jon  Erickson 

30  Sep  2010 

SEA  073, 
Undersea 
Technology  Office 

073RX 

•  Guidance  on  the  key  technical  points 

Mr.  David  White 

01  Oct  2010 

Littoral  and  Mine 
Warfare  Design 
and  Systems 
Engineering 

Deputy 

Director 

SEA  05LB 

•  Recovery  system  is  key 

•  Power  is  constraint 

•  Desire  a  standard  UUV  which  could 
be  configured  with  multiple  sensors 

Mr.  Steve  Southard 

08  Oct  2010 
And 

16  Mar  2011 

NAVSEA  05T 
Technology  Group 

(This  organization 
is  responsible  for 
integration  of  new 
technology  into  the 
navy) 

SEA05T11, 

Division 

Head 

Technology 

Transition 

Division 

•  Support  additional  power 
requirements  (recharging)  or 
communications  be  extendable  from 
100  nm  to  200  nm. 

•  Use  set  based  design  approach  to 
develop  a  range  of  possibilities  to  be 
included  in  specifications 

Dr.  Norbert  Doerry 

Technical 

Director 

Mr.  David  French 

18  Nov  2010 

NUWC  N82 

Technical 
Warrant 
Holder 
(TWH  )  for 
Unmanned 
Undersea 
System 

•  Communications  -  Direct  UUV/host 
sub  communications  hard. 

Recommend  host  sub  communication 
with  satellite  and  one-way 
communication  to  UUV. 

•  Off-board:  Acoustic  Communications 
Issues  -  robustness,  range,  bandwidth, 
content  of  data  messaging 

•  Off-board:  RF  or  SATCOM  with 

UUV,  i.e.  @  PD 

•  Launch  and  Recovery:  Mechanical, 
secure  of  vehicle  (i.e.  stow)  shock, 
vibrations 

•  CONOPS  -  platform  speed  for 
communications,  platfonn  speed  for 
L&R,  Communication  reliability 
during  L&R,  water  space  mgt...., 
depth  of  operations. 

•  UUV  Certification  (the  biggies)  - 
shock,  energy  (stow,  charge, 
discharge,  out  gassing,  etc...), 
implodable  volumes  (limits 
operational  depth  for  L&R) 
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Table  2  -  SME  Interviewees  and  Results  (Continued) 


Name 

Date 

Organization 

Title 

Key  Points 

Mr.  John  Babb 

17  Nov  2010 

NUWC 

Director, 
Confonn 
Office, 
National 
Workload 
Manager  - 
Undersea, 
Warfare 
Systems 

(previous 
worked 
Large  UUV 
integration 
into  SSGN) 

•  Mission  profile  needs  to  be  down 
loaded  by  sub  crew  and  installed  into 
UUV  prior  to  launch. 

•  Work  could  be  done  on  UUV  with 
portable  equipment  -  maintenance 
laptops. 

•  LDUUV  launched  from  back  of  ship. 

•  UUV  would  have  to  be  controlled 
from  submarine  (or  surface  ship)  - 
fiber  optic  or  acoustic  interface. 

•  Sensor  data  transferred  to  sub,  sensor 
field  or  to  another  device,  Hydro 
Acoustic  Information  Link  (HAIL)  is 
one  system. 

•  Digital  acoustic  communications  with 
encryption. 

•  Ship  might  work  with  a  homing 
device.  Look  at  ASDS,  or  DSRV. 

•  A  cradle  might  be  installed  topside 

•  Theoretically,  UUV  could  be  re¬ 
launched  from  a  submarine 

•  A  UUV  operator  can  only  control  one 
UUV  at  a  time  unless  they  were 
working  in  a  leader/fol lower 
situation. 

Mr.  Carlos 
Galliano 

19  Nov  2010 

NUWC  N412 

Payload  and 
Payload 
Integration 
Department  Chief 
Engineer 

TWH  for 
Undersea 
Launcher 
Systems 

•  UUV  launcher  needs  interface  to 
Weapons  control  console  which 
causes  the  gas  generator  to  fire. 

•  MAC  would  be  removed  for  the 
large  UUV  to  be  installed  with 
launcher  interface  or  else  space 
restrictions  would  limit  size  to 
tomahawks 

•  Restraint  system  would  need  to  meet 
Grade  B  shock. 

•  Provided  an  integration  checklist 
which  included  such  things  as 

Physical  Characteristics, 
environmental  considerations, 
material  considerations 

Cmdr  William  B. 
Smith 

15  Mar  2011 

OPNAV  N2N6F2 

Head  of 
Undersea 
Capabilities 
Branch 

•  Goal  is  first  mission  ready  of 

LDUUV  by  2017  with  30  days  up  to 
eventual  120  day  endurance.  Lengths 
of  20  feet  to  45  feet,  increased 
autonomy  and  redundancy. 

•  Submarine  host  platfonn  considered 
desired  but  not  exclusive. 

Dr.  Edward 
Ammeen 

15  Mar  2011 

PMS  450 
Program  Office, 
VA  Class 
Submarines 

PMS  450 
Representative 
for  ULRM/ 
VA  Class 
Integration 
Team 

•  Block  IV  and  V  VPT  designs  still 
under  review. 

•  UUV  “mission  creep”  presents 
problems.  Still  potential  tech  issues 
with  fielding  on  VA  Class  sub. 

•  Greater  teaming  with  UUV 
manufacturers  would  be  beneficial. 

•  Power  technologies  of  a  primary 
concern  (safety/support). 
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-4.  Analysis  of  Interviews/Research 
a.  Operational  Setting 

Submarine  based  large  UUV  systems  provide  a  broad  spectrum  of  ISR  collection 
capability  to  support  joint  combatant  forces  in  worldwide  peace,  crisis,  and  wartime  operations. 
As  discussed  in  the  UUV  Master  Plan  of  2004,  “UUVs  are  uniquely  suited  for  information 
collection  due  to  their  abilities  to  operate  at  long  standoff  distances,  operate  in  shallow  water 
areas,  operate  autonomously,  and  provide  a  level  of  clandestine  capability  not  available  with 
other  systems.”  The  capabilities  of  the  UUV  systems,  coupled  with  the  host  submarine,  provide 
for  adaptive  real  time  planning  of  current  operations  to  include;  monitoring  enemy  offensive  and 
defensive  positions,  deception  postures  and  combat  assessments.  This  includes  missions  in 
support  of  battle  assessment  and  the  global  war  on  terror.  This  system  of  systems  will  provide  a 
rapid  turnaround  of  raw  data  to  aid  a  robust  targeting  cycle.  Figure  7  below  provides  examples 
of  threats  and  consequences,  which  could  be  deterred  /mitigated  by  persistent-ISR  UUV 
operation  in  a  littoral  area. 
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USS  Cole  Bombing  [Maritime  Quest,  2000] 

Figure  7  -  Threats  Suited  to  Deterrence  by  Persistent-ISR  UUV  Operations 

VA  Class  Block  III  submarines  will  be  aligned  under  Commander,  Submarine  Forces 
Command/Submarine  Force  Atlantic/Allied  Submarine  Command  and  Commander  Submarine 
Forces  Pacific  and  assigned  to  an  Atlantic  or  Pacific  Fleet  Squadron  (e.g.,  Norfolk  or  New 
London,  and  Pearl  Harbor).  Figure  8  and  Figure  9  provide  a  view  of  this  command  structure. 
Submarine  commands  are  organized  by  operations  and  maintenance.  All  personnel  will  have  a 
commitment  to  deploy  in  support  of  tactical  operations  or  other  tasking.  The  capability  to 
support  launch,  replenishment  and  recovery  of  a  Large  Vehicle  Class  UUV  from  a  VA  Class 
Block  III  submarine  will  provide  twenty-four  hour,  high-quality  sensor  coverage  of  a  critical 
Area  of  Operation  (AO),  giving  the  theater  Commander  in  Charge  (CINC)  intelligence 
advantages  over  potential  enemies  and  threats. 
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Figure  8  -  Naval  Command  Structure 
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Figure  9  -  Submarine  Force  Organization  Structure 
b.  System  Functionality  and  Tasks 

The  Uniform  Navy  Tactical  Task  List  [UNTL,  Jan  2007]  was  utilized  to  focus 
stakeholder  wants  and  desires  into  a  context  of  standard  tasks  the  UUV/Launch  and  Recovery 
Mechanism/Host  Sub  FOS  should  perform.  This  hierarchy  of  tasks,  outlined  in  Table  3  below, 
provided  an  initial  basis  for  a  concept  of  operations  for  the  FOS  and  supported  future  functional 
and  architectural  development.  It  provided  starting  points  for  the  team  to  develop  measures  of 
perfonnance  (MOP)  for  the  launch  and  recovery  system  functions  and  assisted  in  defining 
achievable  and  clear  needs  from  interview  responses  and  literature. 
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Table  3  -  Hierarchy  of  System  Tasks 


Naval  Tactical 
Task  (NTA) 

Description 

1. 

DEPLOY/CONDUCT  MANEUVERS 

1.1 

Move  Naval  Tactical  Forces  -  [Move  naval  units  and  their  systems  from 
one  position  to  another  in  order  to  gain  an  advantage  or  avoid  a 
disadvantage] 

1.1.2 

Move  Forces 

1. 1.2.5 

Employ  Remotely  Operated  Vehicles  (ROVs) 

1.2 

Navigate  and  Close  Forces  -  [Determine  track  for  movement  of  naval 
forces  to  overcome  challenges] 

1.2.8 

Conduct  Tactical  Reconnaissance  and  Surveillance 

2. 

DEVELOP  INTELLIGENCE 

2.2 

Perform  Collection  Operations  and  Management  -  [Gather  data, 
information  and  previous  intelligence  to  satisfy  identified  requirements] 

2.2.2 

Collect  Tactical  Intelligence  on  Situation 

2.2.3 

Perform  Tactical  Reconnaissance  and  Surveillance 

6. 

PROTECT  THE  FORCE 

6.1 

Enhance  Survivability  -  [Protect  personnel  and  resources  from  enemy 
and  friendly  operations  and  systems  and  natural  occurrences] 

6.1.1 

Protect  Against  Combat  Area  Hazards 

6.1.2 

Conduct  Perception  Management 

Four  (4)  main  tactical  tasks  defined  the  purpose  of  the  UUV/Launch  and  Recovery 
Mechanism/Host  Sub  family  of  systems: 

•  Move  Naval  Tactical  Forces 

•  Navigate  and  Close  Forces 

•  Perform  Collection  Operations  and  Management 

•  Enhance  Survivability 

Team  analysis  of  these  tasks  detennined  top-level  functions  performed  by  the  LRS  must 
include,  as  a  minimum,  launch,  recover,  communicate,  replenish  and  stow.  With  respect  to  these 
functions,  team  members  articulated  system  needs  and  ensured  that  needs  defined  for  the  project 
did  not  encompass  an  attribute  outside  the  bounds  of  the  LRS.  For  instance,  the  Special 
Operations  Command  -  Naval  Science  and  Technology  Strategic  Plan  of  2009  [USSOCOM, 
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2009]  recognize  that  advanced  power  systems  are  needed  to  support  persistent-ISR  missions  with 
UUVs.  Concepts  may  include  larger,  renewable  systems,  which  place  more  demand  on  UUV 
charging  sources.  However,  this  project’s  scope  did  not  include  development  of  new  power 
systems,  a  component  inherent  to  UUVs  themselves,  but  instead  focused  on  flexibility  of  the 
LRS  to  support  future  concept  changes  and  upgrades. 

c.  Stakeholder  Value  System 

To  support  development  and  ranking  of  stakeholder  needs  by  the  Capstone  team,  a 
stakeholder  value  system  was  established.  The  stakeholder  value  system  reflected  not  only  the 
needs  of  the  stakeholders,  as  determined  through  literature  search  and  interviews,  but  also 
assigned  an  importance  to  each  need  with  respect  to  other  needs.  The  team  identified  the  four 
(4)  most  important  stakeholder’s  needs  as: 

•  Operational  Safety 

•  Support  Increasing  Power  Demands 

•  Launch  and  Recovery  Performance 

•  Minimization  of  Life  Cycle  Costs  (LCC)  (Acquisition,  Maintainability  and 
Reliability  Considerations) 

5.  Conclusions 

Using  the  results  of  stakeholder  needs  analysis,  the  team  developed  a  list  of  requirements 
for  the  system.  To  rank  the  importance  and  weight  the  requirements,  each  team  member 
accomplished  a  pair-wise  comparison,  using  the  stakeholder  values  and  team  member 
knowledge/experience.  The  cumulative  results  of  the  pair-wise  comparisons  are  provided  in 
Figure  10.  Figure  1 1  displays  the  ranked  and  weighted  stakeholder  needs  in  descending  order  of 
importance,  which  demonstrated  a  consistent  reflection  of  the  established  value  system. 
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1.  Flexible  to  accommodate  multiple 

size/shape  UUVs 

2.  Support  multiple 

packages/launches  simultaneously 

3.  Accommodate  large  power 

sources/re-charging 

4.  System  Weight 

5.  Affordable 

6.  Resist  shock  and  noise  conditions 

7.  Launch/recover  performance 

parameters  (time/stealth/moving  sub) 

8.  Reliable 

9.  Host  ship  safety 

10.  Maintainable  at  Sea 

11.  Interface  communications 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

Weight 

1.  Flexible  to  accommodate  multiple  size/shape  UUVs 

1 

1 

2.930 

0.268 

1.690 

1.274 

0.908 

0.725 

0.342 

0.303 

1.152 

1.295 

0.073 

2.  Support  multiple  packages/launches  simultaneously 

2 

0.341 

1 

1.226 

1.060 

0.620 

1.255 

0.962 

0.358 

0.454 

0.374 

0.744 

0.052 

3.  Accommodate  large  power  sources/re-charging 

3 

3.733 

0.816 

1 

3.179 

2.255 

1.748 

1.445 

1.687 

1.163 

2.251 

0.783 

0.123 

4.  System  Weight 

4 

0.592 

0.944 

0.315 

1 

1.838 

1.738 

1.337 

0.770 

0.239 

2.231 

0.665 

0.072 

5.  Affordable 

5 

0.785 

1.614 

0.444 

0.544 

1 

1.944 

1.854 

1.040 

0.324 

2.667 

2.667 

0.091 

6.  Resist  shock  and  noise  conditions 

6 

1.101 

0.797 

0.572 

0.575 

0.514 

1 

2.345 

2.962 

1.549 

2.929 

2.250 

0.102 

7.  Launch/recover  performance  parameters  (time/stealth/moving  sub) 

7 

1.379 

1.040 

0.692 

0.748 

0.539 

0.426 

1 

3.393 

1.741 

3.179 

4.076 

0.112 

8.  Reliable 

8 

2.921 

2.796 

0.593 

1.298 

0.961 

0.338 

0.295 

1 

0.497 

3.571 

2.135 

0.101 

9.  Host  ship  safety 

9 

3.301 

2.205 

0.859 

4.186 

3.084 

0.646 

0.574 

2.013 

1 

5.048 

4.786 

0.170 

10.  Maintainable  at  Sea 

10 

0.868 

2.671 

0.444 

0.448 

0.375 

0.341 

0.315 

0.280 

0.198 

1 

1.992 

0.055 

11.  Interface  communications 

11 

0.772 

1.343 

1.278 

1.504 

0.375 

0.444 

0.245 

0.468 

0.209 

0.502 

1 

0.050 

Figure  10  -  Cumulative  Pair-Wise  Comparison  Results 


Figure  11  -  Ranked  and  Weighted  Stakeholder  Requirements 
B.  FUNCTIONAL  ARCHITECTURE 
1.  Background 

Once  functional,  perfonnance,  interface,  and  other  requirements  were  identified,  a 


functional  analysis  was  perfonned  to  form  a  coherent  description  of  system  functions  and 
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performance,  in  the  fonn  of  a  functional  architecture.  This  was  accomplished  by  arranging 
functions  in  logical  sequences,  decomposing  higher-level  functions  into  lower-level  functions, 
and  allocating  performance  from  higher-  to  lower-level  functions. 

In  order  to  do  this,  functional  hierarchy  diagrams  were  first  developed.  These  diagrams 
identified  top-level  functions,  and  successively  define  lower-level  functional  and  performance 
requirements  at  ever-increasing  levels  of  detail.  This  was  done  until  there  was  sufficient  detail  to 
provide  design  and  verification  criteria  to  support  the  integrated  system  design.  These  diagrams 
were  used  to  trace  the  requirements  back  to  the  stakeholder  needs. 

Integration  Definition  for  Function  Modeling  was  also  performed,  resulting  in  IDEFO 
models.  IDEFO  models  defined  process  and  data  flows.  They  were  composed  of  functions,  and 
data  and  objects  that  inter-relate  those  functions.  IDEFOs  illustrated  controls,  inputs,  data  or 
objects  acted  upon  by  inputs,  and  mechanisms  that  provided  supporting  means  for  perfonning  a 
function. 

Finally,  Enhanced  Functional  Flow  Block  Diagrams  (EFFBs)  were  developed.  These 
described  the  systems  functions  and  the  order  in  which  they  are  to  be  executed. 

2.  Architectural  Views  and  Products 

The  LRS  functions  were  decomposed  and  the  architecture  of  the  system  was  created. 

The  systems  engineering  tool,  CORE®,  by  Vitech  Corporation,  was  used  to  conduct  the  analysis. 
The  analysis  consisted  of  mapping  functions,  operational  activities,  perfonners,  and  requirements 
to  each  other  to  ensure  all  attributes  correlated  and  to  determine  if  any  gaps  existed.  Several 
Department  of  Defense  Architectural  Framework  (DoDAF)  views  were  created  to  display  this 
information. 
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a.  System  Functional  Hierarchy 

The  team  analyzed  the  functions  that  were  derived  in  the  requirements  analysis.  It  was 
determined  that  the  LRS  has  four  top-level  functions  and  all  other  functions  are  sub-functions  of 
these.  The  top-level  functions  for  the  LRS  are:  “Launch”;  “Recover”;  “Replenish”  and 
“Maintain”. 

Launch  Functional  Hierarchy 

Launch  -  This  function  prepares  the  LRS  and  then  executes  the  launch  of  the  UUV  from 
the  HostSub  Payload  Tube.  The  launch  function  consists  of  initiating  the  launch;  commutating 
with  the  external  systems  which  it  interfaces  (HostSub  and  UUV),  to  upload  mission  data; 
obtaining  the  HostSub  environmental  data  and  then  using  this  data  to  determine  system 
readiness;  and  finally  executing  the  launch  of  the  UUV.  The  launch  functional  hierarchy  is 
displayed  in  Figure  12. 
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1.0  Launch 


1 . 1  Initiate  Launch  Sequence 

1 .2  Communicate 

1.2.1  Establish  LRS  -  Host  Sub 

1.2.2  Establish  LRS  -  UUV  Communications 
Link 

1.2.3  Download  ISR  from  HOSTSUB 

1 .2.4  Upload  ISR  Data  to  UUV 

1.3  Obtain  Environmental  Information 

1.3.1  Determine  Host  Sub/UUV  Depth 

1.3.2  Determine  threats  (geological/enemy) 

1.3.3  Determine  Host  Sub/UUV  Speed 

1 .4  Determine  System  Readiness 

1.4.1  Receive  indication  ofUUV(s)  readiness 
level 

1.4.2  Perfonn  Self-Check  of  LRS 

1.4.3  Determine  LRS  Ready  Status 

1.4.4  Communicate  (to  host  ship)  LRS  ready 
to  launch 

1.4.5  Receive  indication  of  Host  Sub 
readiness  level 

1.5  Execute  Launch 

1.5.1  Unsecure/unlock  LRS  from  tube 

1.5.2  Extend  LRS 

1.5.3  Release  UUV(s) 

1.5.4  Retract  LRS 

1.5.5  Resecure/lock  LRS  in  Payload  Tube 


Figure  12  -  Launch  Functional  Hierarchy 
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Recover  Functional  Hierarchy 


Recover  -  The  recovery  function  prepares  the  LRS  and  executes  the  recovery  of  the  UUV 
until  the  UUV  and  LRS  are  stowed  in  the  HostSub  Payload  Tube.  The  recovery  function  is 
similar  to  the  launch  function  in  that  it  established  communications  with  the  HostSub,  obtained 
environmental  information  and  assesses  whether  the  LRS  is  ready  to  recover  the  UUV.  The 
recover  function  also  has  the  capability  to  execute  the  recovery  by  extending  the  LRS,  activating 
the  location  device,  capturing  the  UUV  and  then  retracting  the  recovery  mechanism.  The  UUV 
will  be  secured  to  the  LRS  which  will  engage  and  lock  in  the  HostSub  Payload  Tube.  Recovery 
functional  hierarchy  is  displayed  in  Figure  13. 

2.0  Recover 

2.1  Initiate  Recovery  Sequence 

2.2  Communicate 

2.2. 1  Establish  UUV  -  LRS  -  Host  Sub 
Communications  Link 

2.2.2  Transmit  Data  between  LRS  -  HOSUB 

2.3  Obtain  Environmental  Information 

2.3.1  Determine  Host  Sub/UUV  Depth 

2.3.2  Determine  Threats  (geological/enemy) 

2.3.3  Determine  Host  Sub/UUV  Speed 

2.4  Detennine  System  Readiness 

2.4.1  Receive  indications  of  Host  Sub  readiness 
level 

2.4.2  Perform  Self-Check  of  LRS 

2.4.3  Determine  LRS  Ready  Status 

2.4.4  Communicate  LRS  ready  to  recover 

2.4.5  Receive  indication  of  Host  Sub 

2.5  Execute  Recovery 

2.5.1  Extend  LRS 

2.5.2  Activate  Location  Device 

2.5.3  Grab  UUV 
2.5.4.  Verify  UUV  Grab 

2.5.5  Retract  Recover  Mechanism 
2.6  Secure  LRS 

2.6.1  Obtain  information  that  retraction  is  complete 

2.6.2  Engage  lock 

2.6.3  Confirm  status  of  locking  mechanism 
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Figure  13  -  Recovery  Functional  Hierarchy 
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Replenish  Functional  Hierarchy 

Replenish  -  This  function  consists  of  the  LRS  providing  the  interface  between  the  UUV 
and  the  HostSub  to  replenish  the  UUV  for  the  next  mission.  The  LRS  has  the  capability  to  refuel 
the  UUV  and  will  also  be  able  to  establish  connections  with  the  HostSub  and  the  UUV  to 
upload/download  mission  data.  Replenish  functional  hierarchy  is  displayed  in  Figure  14. 


Figure  14  -  Replenish  Functional  Hierarchy 


Maintain  Functional  Hierarchy 


Maintain  -  This  function  consists  of  providing  diagnostics  of  the  LRS  and  providing 
underway  repair  and  maintenance.  This  function  is  all  inclusive  and  does  not  interface  with  any 
other  system.  The  Maintain  functional  hierarchy  is  displayed  in  Figure  15. 
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Figure  15  -  Maintain  Functional  Hierarchy 
b.  Allocation  of  Functions  to  Components 

Once  the  functional  hierarchy  was  established,  each  function  was  mapped  to  the 


corresponding  operational  activity,  performer,  component  and  requirement  to  provide 


traceability.  This  ensured  that  all  attributes  were  defined  and  allocated.  The  IDEFO  graphical 


output  from  CORE®  was  used  to  describe  the  allocation  of  the  system  functions  to  its 


components. 


(1)  Traceability  to  System  Requirements 

A  part  of  tracing  the  functions  to  system  requirements  included  mapping  the  functions  to 
their  forms  during  the  decomposition  to  ensure  every  function  had  a  component.  Figure  16 
provides  a  tabular  mapping  to  identify  the  system  function  allocations  to  the  components. 
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Function 


Initiate  Launch  Sequence 

rn 

mm 

Communicate  to  Support  Launch 

Efl 

Obtain  Environmental  Launched  Based  Information 

1:1 

Determine  System  Readiness 

mm 

Execute  Launch 

mm 

mm 

Initiate  Recovery  Sequence 

mm 

F.2.2 

Communicate  to  Support  Recovery 

mm 

X 

X 

F.2.3 

Obtain  Environmental  Information 

mm 

Determine  System  Readiness  for  Recovery 

mm 

F.2.5 

Execute  Recovery 

mm 

mm 

X 

X 

F.2.6 

Secure  UUV 

mm 

Establish  connection  with  UUV/HostSub 

mm 

mm 

Transfer  data  from/to  UUV 

ii 

Transfer  data  from/to  HostSub 

mm 

Repower  UUV 

wm 

|  F.3.5 

Release  connection  with  UUV/HostSub 

mi 

mm 

Perform  on-board  diagnostics 

mm 

mm 

F.4.2 

Accomplish  underway  maintenance 

mm 

Figure  16  -  Form  vs.  Decomposed  Functions 
c.  System  Performers  and  Information  Needs 

The  LRS  has  one  top  level  system  perfonner,  the  LRS  operator.  The  LRS  operator 
interfaces  with  two  external  systems  -  the  UUV,  which  is  autonomous,  and  the  HostSub 
operator.  The  DoDAF  OV-2,  which  is  presented  in  Figure  17,  displays  the  operational  nodes 
with  the  informational  need  lines  that  connect  the  LRS  to  the  external  systems.  This  infonnation 
triggers  the  system  to  perfonn  the  launch  and  recovery  functions.  The  infonnation  passed 
between  these  interfaces  includes  information  collected  during  the  mission  as  well  as  infonnation 
to  maintain  the  LRS  and  determine  if  it  is  ready  to  perform  a  certain  function. 

In  addition  to  the  top-level  interface,  to  provide  a  more  detailed  view  of  the  system,  there 
are  two  other  performers  that  were  mapped.  These  are  the  operational  nodes,  which  connect  to 
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the  HostSub,  the  US  Navy  Support  Agency  and  the  UUV  Equipment  Providers.  The  US  Navy 
Support  Agency  are  where  the  mission  parameters  are  generated  and  all  information  collected 
during  the  mission  is  sent.  The  UUV  equipment  providers  help  troubleshoot  the  UUV  while 
underway.  While  maintaining  the  UUV  is  outside  of  the  scope  of  this  document,  it  was 
recognized  since  it  is  a  critical  attribute  in  having  the  LRS  mission  be  successful. 


Figure  17  -  System  Performers  and  Information  Needs 
d.  Operational  Flows 

The  system  operational  views  were  displayed  via  the  extended  functional  flow  block 
diagram  and  the  IDEFO  views  that  were  generated  in  CORE®.  This  view  displays  the 
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information  given  in  the  DoDAF  OV-5  and  SV-4  views.  Both  the  EFFBD  and  the  IDEFO  give 
the  controls,  inputs  and  output,  operational  activities  and  functions;  the  EFFBD  shows  the 
sequence  of  activities  whereas  the  IDEFO  shows  the  allocation  of  operational  activities,  and 
input/outputs  and  controls  better  than  the  EFFBD. 

Launch  IDEFO/EFFBD  -  The  launch  EFFBD  and  IDEFO  are  presented  in  Figure  18  and 
Figure  19,  respectively.  The  launch  function  is  started  by  initiating  the  launch  sequence  via  the 
launch  mechanism  that  is  triggered  by  the  UUV  mission  objectives  report  being  supplied  to  the 
system.  Communications,  via  the  control  system,  will  then  be  established  between  the  LRS  and 
HostSub,  and  LRS  and  UUV  to  upload  and  download  required  ISR  mission  data.  The  LRS  has 
the  capability  to  obtain  environmental  information  from  the  HostSub  and  UUV,  including  the 
depth  and  speed  of  the  submarine  and  UUV,  along  with  the  environmental  threats  that  impact 
launching  the  UUV.  This  data  will  be  used  to  determine  if  the  LRS  is  ready  to  launch.  Along 
with  the  environmental  data,  the  LRS  performs  a  self-check  prior  to  declaring  the  LRS  is  ready 
to  launch  the  UUV.  Finally,  the  LRS  undocks  from  the  payload  tube,  extends  to  launch  the  UUV 
and  then  retracts  and  re-docks  into  the  payload  tube.  This  sequence  was  conceived  to  be 
conducted  up  to  three  times  consecutively  to  launch  three  UUVs  during  one  mission. 


Figure  18  -  Launch  EFFBD 
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idefO  Launch  UUV 


UUV  Mission  Objectives  Report 

o 


Initiate  Launch 
Sequence 


LRS  Launch  Initiated  Status 


UUV  Mission  Data 
- \ 


PFTz 


ML 


-Request  for  environmental  Information 


Communicate  to 
Support  Launch 


-Positive  Communicatii  in  Status 


JJi 


O 

Communications  Systems 


Environmental  ^SStiubEnviommental  Report 
Launched  Based 
Information 

n 


-to 


-Host  Sub  Readiness  Status 


Determine  System  ^  Readiness  5tatus 
Readiness 


"F.1.5 


(I)  (I) 


(1) 


^  Launch  Success/Failure  Status 


Control  System  Architecture  \  Launch  Mechanism 
Support  Structure 


Figure  19  -  Launch  IDEF  0 


Recovery  EFFBD/IDEFO  -  The  recovery  function  starts  with  the  UUV  Mission 
objective  status  triggering  the  start  of  the  recovery  sequence  and  whose  EFFBD  and  IDEFO  are 
presented  in  Figure  20  and  Figure  21,  respectively.  Communications,  via  the  control  system  and 
RF  and  acoustic  communications,  will  be  established  between  the  LRS/HostSub  to  obtain 
environmental  information  from  the  HostSub  and  UUV,  including  the  depth  and  speed  of  both 
the  submarine  and  UUV,  along  with  the  environmental  threats  that  would  impact  launching  the 
UUV.  This  data  will  be  used  to  determine  if  the  LRS  is  ready  to  support  recovery.  Along  with 
the  environmental  data,  the  LRS  performs  a  self-  check  prior  to  declaring  the  LRS  is  ready  to 
recover  the  UUV.  Once  the  system  is  ready,  the  LRS  will  extend  and  capture  the  UUV.  The 
UUV  will  then  be  secured  and  locked  into  the  LRS  which  will  then  be  stowed  in  the  HostSub 
Payload  Tube.  Like  the  launch  function,  recovery  can  occur  up  to  three  times  consecutively. 
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Figure  20  -  Recovery  EFFBD 


.ecover  UUV  J 

UUV  Mission  Complete  Status 


Replenish  EFFBD/IDEFO  -  Once  the  LRS  has  recovered  the  UUV,  the  UUV 
replenishment  activities  will  occur.  The  Replenish  EFFBD  and  IDEFO  are  presented  in  Figure 
22  and  Figure  23,  respectively.  This  is  done  by  first  establishing  a  connection  with  both  the 
HostSub  and  UUV  for  power  and  communications.  Information  will  be  uploaded  or  downloaded 
from  the  UUV,  LRS,  and  HostSub,  along  with  repowering  of  the  UUV.  These  events  may  occur 
in  parallel.  Once  the  system  has  determined  that  the  UUV  is  repowered  and  all  information  has 
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been  downloaded  or  uploaded,  the  connection  between  the  UUV,  LRS  and  HostSub  will  be 
terminated. 


effbd  Replenish  UUV  Support  Systems  and  Communicate  Information 
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Figure  22  -  Replenish  EFFBD 


idefO  Replenish  UUV  Support  Systems  and  Communicate  Information 
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UUV  Secured  in  LRS  Successfully  Status 


Host  Sub  Upload/Download  Data  Suite 


Figure  23  -  Replenish  IDEFO 
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Maintain  EFFBD/IDEFO  -  The  last  function  to  be  perfonned  is  maintain  whose  EFFBD 
and  IDEFO  are  presented  in  Figure  24  and  Figure  25,  respectively.  The  LRS  will  provide  a  UUY 
and  LRS  Readiness  status.  The  LRS  in-service  maintenance  component,  a  part  of  the  control 
system  architecture,  will  perform  an  on-board  diagnostic  of  the  system.  If  necessary,  the  system 
will  accomplish  maintenance  and  then  be  ready  for  the  next  mission. 


effbd  Maintain  LRS 


7 


f  LRS  "h  f  UUV  \ 
'Readiness. Readiness  .  I 

— ^  ^ 


F.3 

■F.4.1 

F.4.2 

EXT.F.2 

Replenish  UUV 
Support  System... 

-* 

Perform 

On-Board  Diagn... 

— ► 

Accomplish 
Underway  Main... 

—* 

UUV  Functions 

In-Service  Main... 

In-Service  Main... 

/Maintenanc  \ 
e  Diagnost.. J 


LRS  Ready 
for  Mission 


Figure  24  -  Maintain  EFFBD 


Figure  25  -  Maintain  IDEFO 
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C.  MISSION  ANALYSIS 


1.  Background 

Mission  analysis  was  a  process  which  detennined  the  overall  purposes  or  objectives  and 
capabilities  of  the  system  and  the  circumstances  and  environment  in  which  the  system  must 
operate  [SC-21,  1998],  Figure  26  identified  the  activities  and  process  used  to  support  mission 
analysis.  Mission  analysis  for  this  project  included  analysis  of  stakeholder  needs  and  coupled 
boundary  conditions,  analysis  of  the  specified  areas  of  operations  (AO),  constraints  encountered 
in  the  AO,  threats  to  the  mission,  personnel  and/or  organizational  units  needed  to  support  the 
mission  and  resources  needed  to  successfully  support  the  mission. 

The  mission  analysis  was  used  to  first  develop  a  Concept  of  Operations  (CONOPS)  for 
the  UUV/Launch  and  Recovery  Mechanism/Host  Submarine  Family  of  Systems.  The  CONOPS 
is  a  high-level  viewpoint  of  how  the  system  operates  within  its  intended  environment  and  was 
developed  using  the  list  of  critical  tasks,  derived  from  the  UNTL.  From  this  CONOPS,  specific 
AOs,  constraints  and  threats  were  considered  to  develop  several  important  mission  scenarios  that 
would  be  supported. 

These  mission  scenarios  assessed  the  functionality  of  the  proposed  system  concepts.  The 
functionality  was  traced  upward  to  ensure  that  the  needs  of  the  stakeholders  met  the  plausible 
missions  of  the  system  and  traced  downward  to  measure  perfonnance  of  physical  concepts 
against  each  other.  With  these  mission  scenarios,  the  project  team  analyzed  the  operational 
environment  and  boundaries  of  the  system  and  identified  potential  interactions  with  external 
entities,  which  might  have  been  otherwise  missed,  and  created  perfonnance  requirements  for  the 
system. 
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Identify  Mission 
Objectives/Needs 


Identify 

Operational 

Environment 


Identify  System 
Boundaries 


Define  CONOPS 


Define  Mission 
Phases/Threats 


Identify  System 
Constraints 


Define  Mission 
Scenarios 


Figure  26  -  Mission  Analysis  Process  Diagram  [SC-21, 1998] 
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2. 


External  Boundary  Conditions 


a.  UUV  System 

There  are  numerous  large  UUVs  built  for  ISR-type  operations  by  different  vendors.  To 
support  the  success  of  this  project  and  define  the  interfaces  necessary  to  support  integration,  a 
“standard”  Large  Vehicle  Class  UUV  system  was  defined.  The  “standard”  Large  Vehicle  Class 
UUV  captured  most,  if  not  all,  of  the  major  performance  requirements  and  functions  inherent  to 
currently  conceived  large  UUV  systems.  The  following  sources  were  used  to  capture  the  major 
requirements  and  functions: 

•  Overarching  system  design  requirements  specified  in  the  UUV  Road  Map  Report 
issued  by  NAVSEA  073R,  Director  of  Undersea  Technology.  [SEA  073R,  2008] 

•  The  Survey  of  Large  Unmanned  Maritime  Vehicles  prepared  by  Johns  Hopkins 
Applied  Physics  Laboratory  [Hopkins,  2010] 

•  The  identified  mission  requirements  based  on  the  Stake  Holder  Goals  concerning 
CNO  Requirements  for  a  30  Day  Mission  in  Seven  Years  from  ’’Inside  The  Navy” 
[Inside  The  Navy,  2010] 

•  The  technology  requirements  based  on  the  infonnation  specified  in  Department  of 
Defense,  Militarily  Critical  Technologies  List  Section  13:  Marine  Systems, 
Technology,  January  2009,  Under  Secretary  of  Defense,  Acquisition,  Technology  and 
Logistics  Pentagon.  [MCTL,  2009,  Section  13] 

•  The  review  of  ASTMs  established  to  define  common  parameters  for  UUV 
development.  [ASTM  F2594-07,  ASTM  F2545-07,  ASTM  F2541-06,  ASTM  F2595- 
07] 
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•  Consideration  of  other  technical  factors  and  design  requirement,  including  shock, 
safety  and  commonality. 

Following  examination  of  the  source  documentation,  several  existing  large  UUVs 
designed  for  specific  use  on  ISR-type  missions,  including  Bluefin  Robotics  Corporation 
BPAUV,  Sea  Otter  MK  II  and  REMUS  6000  (see  Figure  27)  were  evaluated  for  common 
features  and  functions.  Through  this  analysis  and  determination  of  threshold  and  objective 
requirements  for  the  existing  systems  as  well  as  review  of  standards  and  possible  developments 
for  “near- future”  systems,  a  “standard”  Large  Vehicle  Class  UUV  were  defined.  Table  4 
provides  the  detailed  attributes  of  the  “standard”  Large  Vehicle  Class  UUV  utilized  for  this 
project. 


Bluefin  BPUAV  [Keller,  2008]  REMUS  6000  UUV  [Kongsberg,  2008] 


SEA  Otter  MK  II  UUV  [AUVAC,  2008] 


Figure  27  -  Typical  Large  Class  Vehicle  UUVs 
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Table  4  -  Parameters  for  “Standard”  Large  Vehicle  UUV 


Attribute 

Low-End/ 

Conventional 

High-End/ 
Cutting  Edge 

“Standard”  Large 
Vehicle  Class  UUV 
Capability 

Length 

12.6  FT 

28.5  FT 

28.5  FT 

Outside  Diameter 

28  IN 

66  IN 

66  IN 

Body  Shape 

Round 

Hydroplane 

Multiple 

Weight  (Dry) 

2000  LBM 

17600  LBM 

20000  LBM 

Operating  Depth 

200  FT 

1000  FT 

1000  FT 

Hovering  Control 

None 

Variable  Ballast 

Tanks 

Variable  Ballast 

Tanks 

Speed 

0-4  Knots 

2-12  Knots 

2-12  Knots 

Range 

22  Hrs  @  4  Knots 

1600  Nm  @3.6 

Knots 

2800  Nm  @  4  Knots 

Propulsion 

Dual  Rotating  Props 

Ducted  Pump  Jet  w/ 

5  Rotating  Blades 

Ducted  Pump  Jet  w/ 

5  Rotating  Blades 

Power/Capacity 

Silver-Zinc  Battery  / 
lOkWh 

Li-Ion  Rechargeable 
Battery  /  360kWh 

Rechargeable 

Battery  /  500kWh 

RF 

Communications 

None 

Freeay  LOS-RF, 
Inmarsat  Sailor-250, 
Iridium  Satellite, 
Inmarsat  Sailor  250 
Satellite 

Freeay  LOS-RF, 
Inmarsat  Sailor-250, 
Iridium  Satellite, 
Inmarsat  Sailor  250 
Satellite 

Acoustic 

Communications 

None 

Custom  WHOI, 
emergency  Comms 
are  Edge  Tech 
Acoustic 
Transponders 

Custom  WHOI, 
emergency  Comms 
are  Edge  Tech 
Acoustic 
Transponders 

UUV  Operational 
Availability  (Ao) 

0.84 

0.95 

0.90 

UUV  Mission 
Duration 

20  Hrs 

18  Days 

30  Days  (Goal) 

UUV  Navigation 
System  Accuracy 

+/-  0.5% 

+/-  0.3% 

+/-  0.5% 

b.  Host  Submarine  System 

The  host  platform  for  this  project  was  the  USS  VIRGINIA  Class  (VA)  Block  III  attack 
submarines.  The  USS  VIRGINIA  (SSN  774)  Class  of  submarines  were  designed  for  both  open- 
ocean  and  littoral  missions.  Their  design  is  a  more  economical  alternative  to  the  Cold  War  era 
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USS  SEAWOLF  Class  (SSN  21)  attack  submarines,  and  will  replace  the  aging  USS  LOS 
ANGELES  Class  (SSN  688)  submarines.  This  class  of  submarine,  designed  by  Electric  Boat 
Corporation,  is  being  jointly  constructed  by  Northrop  Grumman  Newport  News  (NGNN)  in 
Virginia  (now  known  as  Huntington  Ingalls  Industries)  and  Electric  Boat  (EB)  in  Connecticut. 

VA  Block  I  and  II  submarines  are  equipped  with  a  Vertical  Launch  System  (VLS) 
consisting  of  twelve  individual  tubes  located  in  the  forward  section  of  the  submarine.  This  was 
the  SSN  688  Class  attack  submarine  VLS  configuration.  Starting  in  2002,  the  Navy  converted 
four  USS  OHIO  (SSBN  726)  Class  submarines  to  SSGNs.  These  conversions  consisted  of 
modifying  the  existing  88-inch  diameter  ballistic  missile  tubes  to  accommodate  up  to  twenty-two 
(22)  Multiple  All-Up  Round  Canisters  (MAC)  which  provide  the  capability  to  store  and  launch 
seven  Tomahawk  cruise  missiles  while  reserving  the  remaining  two  ballistic  missile  tubes  for 
Special  Operating  Forces  (SOF)  support  or  other  essential  missions.  The  successful  conversion 
of  these  large  diameter  ballistic  missile  tubes  to  MACs  and  other  mission  uses  provided  the  Navy 
justification  to  develop  this  concept  on  the  VA  submarines  in  the  Block  III  hulls.  VA  Block  III 
submarines  will  be  equipped  with  two  larger  diameter  tubes  known  as  Virginia  Payload  Tubes 
(VPT)  in  lieu  of  the  twelve  (12)  individual  VLS  tubes  found  on  Block’s  I  and  II.  Each  payload 
tube  can  accommodate  a  MAC,  used  for  Tomahawk  support,  or  can  be  configured  to  support 
SOF  and/or  UUV  missions.  Figure  28  shows  the  general  configuration  envisioned  for  Block  III 
implementation  of  the  VPT  concept. 
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VIRGINIA  Class  Bow,  Redesign  For  Affordability 

Reduced  Cost,  Increased  Flexibility 


Figure  28  -  Virginia  Class  Block  III  Concept  with  Block  I  /  II  shown  in  Shadow  [Defense 

Daily,  2008] 

3.  Constraints 

A  constraint  is  a  restriction,  regulation,  or  checks  that  prevents,  limits  or  dictates  the 
actions  of  the  system  within  proscribed  bounds.  Through  analysis  of  literature,  needs  and 
operational  concepts,  five  (5)  main  categories  of  constraints  were  identified:  Natural,  Physical, 
Policy,  Operational  and  Man-Made. 

a.  Natural  Constraints 

Ocean  Environment  -  VA  Class  Block  III  submarine  launch,  communication  and 
recovery  of  Large  Vehicle  Class  UUVs  would  be  subject  to  weather  and  sea  state  conditions.  In 
the  worst  sea  conditions,  actual  underwater  launch  and  recovery  may  prove  impossible;  however, 
even  minor  conditions  might  have  an  adverse  impact  on  system  reliability  and  mechanism 
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performance.  Rough  sea  states  or  strong  currents  could  interfere  with  the  transmission  and 
reception  of  data  to/from  the  UUV  and  submarine  or  with  the  navigation  capabilities  necessary  to 
close  and  recover  the  UUV  with  the  mechanism.  Sea  state  and  water  temperatures  could  limit 
replenishment  and  recovery  efforts,  especially  if  manned  operations  are  required.  The 
submarine  might  be  limited  in  its  ability  to  come  to  periscope  depth  to  transmit  data  from  the 
UUV  based  on  weather  conditions.  Warm  Water  Operations  (defined  as  greater  than  90°F)  have 
been  known  to  impact  equipment  reliability,  and  may  contribute  to  contamination  and  fouling. 
Corrosion  of  materials  exposed  to  seawater  must  also  be  considered. 

Topography  -  The  submarine  would  launch  and  recover  UUVs  near  hostile  coastlines. 
Water  depth  at  the  coastline  may  affect  the  ability  for  the  host  submarine  to  approach  the 
coastline.  Currents  may  be  stronger  in  the  intended  operational  environment  than  at  deep-sea 
operations.  Due  to  limited  depths,  underwater  mountains  and  features  may  affect 
communications  and  maneuvering  of  the  equipment.  Shallow  operations  and  extended  periods 
of  hovering  or  on-site  operations  could  result  in  exposure  to  more  marine  life  forms  and 
increased  biological  fouling  of  equipment. 

b.  Physical  Constraints 

Vehicle  Characteristics  -  The  large  diameter,  weight  and  shape  of  current  and  future 
Large  Vehicle  Class  UUVs  would  tax  the  host  submarine  and  the  capabilities  of  a  launch  and 
recovery  system.  Future  iterations  would  expect  larger  power  supplies  for  UUVs  to  support 
persistent-ISR  missions.  The  submarine  must  have  the  capability  to  recharge  the  UUV  power 
supply.  Additionally,  multiple  launch  capabilities  from  a  single  host  submarine  require 
consideration  for  storage  capabilities  within  submarine  launcher  tubes.  To  offset  weight 
additions,  power  impacts  and  shock  considerations,  lightweight  materials  with  equal  strengths  of 
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structural  steels  must  be  considered  in  the  design  of  the  supporting  structure.  Such  materials 
must  successfully  trade  off  cost  considerations  with  performance  considerations. 

Communications  -  The  submarine  communications  suites  have  the  capability  to  interact 
with  the  sensor  suites  on  the  UUV,  through  an  interface  with  the  LRS,  and  retransmit  data  via 
Ultra  High  Frequency  (UHF)  satellite  relay  and  line  of  sight  (LOS)  links  to  maintain  command, 
control,  and  sensor  data  communication  paths.  Bandwidth  compression  would  be  applied  to 
sensor  data  to  maximize  area  coverage  and  data  throughput.  However,  bandwidth  capabilities 
might  be  taxed  as  more  and  more  data  transmission  is  required,  requiring  additional  and  costly 
power  sources.  Furthennore,  timeliness  of  the  transmitted  signals  may  create  problems.  The 
support  command  has  the  responsibility  to  integrate  the  data  transmitted  from  the  submarine 
received  from  the  UUV  into  the  theater  Defense  Infonnation  Infrastructure  (DII)  to  provide 
timely  dissemination  of  collected  intelligence  to  the  requesting  customer, 
c.  Policy  Constraints 

Tasking  Order  -  The  means  for  implementing  persistent-ISR  missions  for  a  VA  Class 
submarine  was  assumed  to  be  the  tasking  order.  The  Tasking  Order  would  include  the 
employment  plan.  The  Fleet  Commander  tasks  the  submarine  to  launch  UUVs  to  accomplish 
specific  missions  and  to  provide  data  with  sufficient  detail  to  execute  persistent-ISR  missions. 
The  support  element  must  be  capable  of  generating  the  mission  plan  within  the  time  constraints 
of  the  tasking  order  cycle.  The  Operational  Commander  issues  the  tasking  order,  which  is  valid 
for  a  specific  period.  The  Operational  Commander’s  Intelligence  Division  would  detennine  that 
the  submarine  launched  UUV  would  conduct  the  mission  based  on  coverage  requirements, 
communications  connectivity  with  supported  units,  and  survivability  considerations.  The 
tasking  order  planning,  coordination  and  execution  is  a  continuous  process,  which  may  cross 
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several  tasking  order  cycles.  The  effective  and  efficient  use  of  submarine  launched  UUVs  for 
persistent-ISR  missions  requires  coordination  between  the  intelligence  and  operational 
commanders  and  multi-service/coalition  liaisons  within  the  command.  During  mission 
execution,  the  commander(s)  support  by  the  data  collected  by  the  UUV  might  request  changes  in 
coverage  areas  or  times.  These  changes  must  be  coordinated  through  the  submarine  immediate 
superior  in  command  (ISIC),  and  Fleet  Commander. 

Water-space  Management  -  The  Fleet  commander  is  responsible  for  the  safe  operation 
of  the  platfonns  under  his  control.  Operating  procedures  with  adequate  margins  of  safety  for 
naval  vessels  in  high  traffic  areas  need  to  be  developed  for  current  and  future  UUV  operations 
Likewise,  the  VA  Class  Block  III  submarine  commander  is  responsible  for  the  safe  operation  of 
his  ship,  the  interfacing  launch/recovery  mechanism  and  the  UUVs.  Policies  must  seamlessly 
integrate  with  over- arching  policies  and  allow  control  of  multiple  UUVs,  possibly  launched  and 
recovered  from  platforms  other  than  the  on-station  host  submarine, 
d.  Operational  Constraints 

Safe  Operations  -  A  system  of  redundant  communications  will  be  required  to  ensure  the 
submarine  can  adequately  navigate  with  and  monitor  UUV  actions  in  close  quarters. 
Considerations  must  be  made  for  a  UUV  vehicle,  which  cannot  make  it  back  to  a  pre¬ 
programmed  recovery  point  and  must  be  abandoned  for  future  recovery  or  destroyed  either  in  a 
high  traffic  sea-lane  or  in  enemy  waters.  The  LRS  must  consider  speed  and  flexibility  of 
recovery,  both  features  which  will  likely  result  in  increased  costs. 

Force  Structure  -  In  general,  the  U.S.  Navy  requires  multiple  VA  Class  submarines  with 
the  capability  to  launch,  control  and  recover  large  UUVs  for  persistent-ISR  missions,  be 
available  in  the  operational  area  to  support  training  and  exercises.  The  UUV’s  coverage 
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constraints  are  dictated  by  power  supply  constraints,  transit  distances  to  the  operational  area  and 
the  ability  to  recover  UUVs  once  deployed. 

Manpower  -  As  the  VA  Class  Block  III  Submarines  are  certified  for  unrestricted 
operations,  the  Commander  Submarine  Forces  Command  must  consider  training  and  equipping 
the  force  for  operations  and  maintenance  of  the  LRS. 

Physical  Security  -  Submarine  and  UUV  protection  requirements  are  based  on  the 
location  of  the  submarine,  the  tasked  mission,  and  the  Department  of  the  Navy’s  physical  and 
operational  security  programs.  Commander  Fleet  Forces  Command,  in  conjunction  with  the 
Office  of  Naval  Intelligence  will  need  to  develop  and  implement  any  additional  physical  security 
requirements  for  the  VA  Class  Block  III  submarines  when  UUVS  are  loaded  with  the  appropriate 
support  systems  installed.  The  standards  will  identify  the  security  priorities  and  establish 
requirements  for  security  forces  and  equipment  aids. 

Information  Security  -  These  requirements  include  addressing  anti-tamper  and  force 
protection  requirements  with  both  received  and  distributed  infonnation.  The  information  that 
needs  to  be  protected  will  include  the  mission  profile,  and  associated  operational  orders  and 
constraint,  and  the  data  collected  during  the  ISR  Missions. 

Operational  Security  -  Operational  Security  requirements  are  designed  to  prevent 
tampering  with  critical  information.  In  this  case,  it  includes  the  control  systems  architecture  and 
the  communications  system,  both  of  which  must  be  maintained  secure.  This  is  done  by  the  use 
of  controlled  work  packages  for  maintenance  and  configuration  changes,  as  well  as  encrypted 
secure  communications.  It  is  anticipated  that  the  existing  radio  and  acoustic  communications 
systems  shall  meet  these  requirements. 
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e.  Man-Made  Constraints 

Enemy  Actions  -  Communications  systems  were  engineered  to  minimize  susceptibility 
to  jamming  and  interception.  Dissemination  of  UUV  collected  intelligence  sent  to  the  submarine 
is  made  through  direct  downlinks  to  national,  theater  intelligence  centers,  and  exploitation 
systems.  As  the  proposed  system  acts  as  a  bridge  between  the  UUV  and  the  host  submarine, 
considerations  must  be  made  to  limit  jamming  and  signal  disruption  by  enemy  forces  and/or 
spurious  signals.  Additionally,  components  used  to  launch  and  recover  the  UUVs  must  consider 
minimizing  radiated  noise  and/or  signature  to  minimize  detection  by  enemy  threats. 

Noise/Information  Pollution  -  Operation  in  littoral  areas  are  known  to  be  extremely 
noisy  environments  and  pose  issues  not  only  to  detection,  but  also  to  collecting  information  on 
targets  and  disseminating  information.  Sensor  design  and  power  requirements  demand  larger 
vehicles  to  meet  persistent-ISR  capabilities.  Override  controls  potentially  necessary  to  support 
maneuvering  operations  of  UUVs  at  launch  and  recovery  must  be  robust  enough  to  overcome 
background  noise  and  interference. 

4.  Mission  Phases  and  Threats 

There  are  four  (4)  distinct  mission  phases  for  the  LRS:  Pre-Mission  (includes  transport, 
loading  and  securing  of  the  UUV  and  launch/recovery  mechanism  into  the  host  submarine), 
Launch  (includes  download  of  mission  parameters),  Recovery  (including  stowage  of  UUV  into 
launch/recovery  mechanism  and  securing  of  equipment)  and  Post-Mission  (including  download 
of  ISR  data,  and  in-service  maintenance  and  troubleshooting/diagnostics).  Each  phase  of  the 
mission  face  a  certain  level  of  risk  associated  with  common  and/or  unique  threats  to  that  phase. 

A  threat  is  a  plausible  risk  that  could  inflict  hann  on  either  personnel  and/or  equipment. 
Threats  might  be  the  result  of  natural  events,  accidents  or  intentional  acts  meant  to  cause  harm. 
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Plausible  threats  to  the  family  of  systems  (UUV,  host  submarine  and  launch/recovery  system)  in 
each  phase  of  the  mission  were  examined  as  follows: 

Pre-Mission  -  Threats  to  equipment  and  personnel  include  accidental  damage  during  the 
loading  operations  and/or  transport.  The  Large  Vehicle  Class  UUVs  can  weigh  as  much  as 
20,000  lbs  and  the  LRS  is  likely  to  weigh  up  to  100,000  lbs.  As  such,  crane  operations  will  be 
required  to  support  loading  into  the  launcher  tubes.  Tight  clearances  and  typical  risks  associate 
with  heavy  lifting  operations  can  lead  to  damage  to  the  LRS,  UUV  and/or  the  host  submarine. 

Of  critical  concern,  is  the  damage  than  cannot  be  visually  detected,  such  as  internal  damage  to 
computer  systems,  communication  systems  or  any  equipment  with  internal  components.  A 
robust  testing  strategy  and  pre-mission  inspection  capabilities  would  aid  in  evaluation  of  system 
capabilities  prior  to  deployment  of  the  loaded  system. 

Launch  -  A  rapid  and  silent  launch  will  be  critical  to  avoid  submarine  and/or  UUV 
detection  by  enemy  forces.  Both  the  submarine  and  the  UUV  are  vulnerable  to  threats  during 
launch  given  its  submerged  operating  envelope.  Operational  concepts  identified  that  the 
submarine  would  launch  UUVs  at  shallow  depths  (no  less  than  periscope  depth).  At  shallow 
depths,  the  threat  to  the  submarine  is  broad,  from  detection  by  enemy  sonar  and  radars  to  visual 
detection,  leading  to  torpedo  and  missile  attack.  Rapid  launch  would  constrain  deployment  times 
of  LRS  components,  requiring  robust,  flexible  and  technologically  advanced  equipment  to 
prevent  damage  from  accidents  and  sea  conditions  at  shallow  depths.  Additionally,  the 
communications  between  the  submarine  and  the  UUV  via  the  interface  of  the  LRS  during  the 
launch  phase  must  be  suitable  to  prevent  deployment  of  a  UUV  with  incomplete  or  inaccurate 
mission  data.  Although  upload  of  information  and  mission  parameters  would  likely  feedback 
erroneous  information  to  operators,  problem  with  the  data  interfaces  could  produce  false 
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readings.  Furthennore,  positioning  of  host  submarine  and  LRS  equipment  will  be  vital  to 
ensuring  impact  accidents  do  not  occur.  Sensor  feedback  mechanisms  must  be  robust  and 
redundant  to  the  necessary  level  of  reliability. 

Recovery  -  Similar  to  the  launch  phase,  rapid  and  silent  recoveries  of  the  UUVs  would 
be  critical  to  avoid  detection.  As  discussed  before,  the  submarine  would  recover  the  UUV  at 
shallow  depths,  where  enemy  risks  of  detection  and/or  hann  are  significant.  Recoveries  would 
likely  pose  a  more  significant  risk  of  accident  as  the  UUV  is  affected  by  ocean  movement 
currents/tides  and  may  not  be  directly  attached  to  the  LRS  as  it  is  during  launch.  Clear  and  real¬ 
time  operator  feedback  would  be  essential  to  prevent  the  UUV  from  damaging  itself,  the  host 
submarine  and  the  LRS  from  accidental  impacts.  In  addition,  recovery  encompasses  secure 
stowage  of  the  LRS  as  well  as  the  UUV  itself.  Vibrations  must  be  minimized  to  avoid  radiated 
noise  and  equipment  damage  due  to  shock  and  other  lesser  differential  forces.  Equipment  must 
minimize  slop  between  components  and  false  readings  concerning  interface  between  the  internal 
and  external  system  boundaries.  Finally,  recovery  might  require  the  use  of  an  active  acoustic 
communication  feature  (such  as  a  sonar  “pinger”)  that  locates  the  UUV  and  provides  a  “homing” 
feature.  Any  such  acoustic  communications  feature  could  lead  to  detection  by  enemy  forces  and 
compromise  of  the  UUV  and  host  submarine  assets  if  not  judiciously  and  sporadically  deployed. 

Post-Mission  -  Interfaces  between  the  UUV  and  the  host  platfonn  must  be  robust  and 
compatible  to  support  a  rapid  transition  of  the  ISR  data  to  the  intelligence  network.  Systems 
where  communications  flow  through  a  wireless  means  may  be  more  rapid  than  a  hardware 
solution,  but  might  also  be  more  susceptible  to  compromise.  Threats  could  include  active  and 
passive  detection  capabilities  by  enemies  and  well  as  interception,  requiring  a  level  of  encryption 
and  security  that  may  further  inhibit  timely  infonnation  transfer.  Post-mission  activities  were 
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expected  to  include  diagnostic  and  trouble-shooting  activities  to  prepare  the  family  of  systems 
for  subsequent  missions.  Such  activities  must  provide  a  technically  sound  and,  at  times,  a 
cautious  approach  to  prevent  hardware/software  damage  to  system  components.  Limits  to 
underway  repairs  must  be  recognized  and  logistics  must  support  on-board  equipment  or 
redundant  components  that  maximize  times  between  mission  failures.  In  addition  to  trouble¬ 
shooting  and  diagnostics,  replenishment  of  the  UUV  through  the  LRS,  primarily  re-charging  of 
the  UUV  power  source,  will  occur.  Accidents  such  as  an  electrical  fire,  power  surge  or  an 
interface  capability  issue  could  damage  the  equipment  or  delay  subsequent  missions. 

5.  Concept  of  Operations 

The  Large  Vehicle  Class  UUV  LRS  was  the  interface  system  between  a  FOS,  brought 
together  to  support  persistent-ISR  underwater  missions  such  as  intelligence  collection,  target 
detection  and  undersea  mapping.  The  LRS  will  be  installed  into  a  VA  Class  Block  III  submarine 
VPT  dockside  prior  to  submarine  deployment.  A  single  or  multiple  Large  Vehicle  Class  UUVs 
will  likewise  be  loaded  onto  the  submarine  prior  to  submarine  deployment  and  physical 
integration  between  the  host  submarine  and  the  UUVs  will  be  accomplished  through  the  LRS. 

During  host  submarine  deployment  to  an  area  of  operations,  mission  information  will  be 
received  and  up-loaded  to  the  UUV(s).  UUV  launch  would  occur  at  a  safe  standoff  position  and 
the  UUV  would  transit  from  this  location  to  the  area  of  interest.  Minimal  operator  control  of  the 
UUV  would  be  expected  to  support  launch.  The  UUV  would  operate  autonomously  and 
clandestinely  within  a  given  range  and  mission  duration.  Mission  updates  and  data  transmissions 
would  occur,  as  necessary,  via  pre-located  communication  buoys,  dropped  by  ships  or  aircraft 
within  the  area  of  operations.  Future  system  upgrades  might  implement  the  capability  for  direct 
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host  submarine  contact  with  the  remote  UUV.  If  host  submarine  communications  would  require 
interaction  between  the  submarine  and  the  UUV,  it  would  be  through  an  upgraded  LRS. 

The  Launch  and  Recovery  Mechanism  Command,  Control  and  Intelligence  (C2I) 
component  provided  the  primary  interface  for  the  UUV  vehicle  to  the  host  submarine.  It  was 
expected  to  be  a  commercial-off-the-shelf  (COTS)  open  architecture  C2I  system,  designed  to 
maintain  positive  control  of  the  LRS  to  prevent  operational  mishaps  such  as  vehicle  casualties, 
collision  or  sensitive  technology  being  compromised  by  foreign  entities  [Unmanned  System 
Safety  Guide  for  DoD  Acquisition  Systems,  27  June  2007]. 

Following  completion  of  the  mission,  the  UUV  would  return  to  a  rendezvous  point  and 
transmit  infonnation  necessary  to  support  acquisition  by  the  host  submarine.  The  host  submarine 
would  recover  the  UUV,  safely  stow  the  vehicle  on  board  and,  if  necessary  transit  to  a  safe  zone. 
Some  operator  control  of  the  UUV  was  anticipated  to  support  recovery  operations.  The  interface 
device  would  support  download  of  data  from  the  UUV  to  the  host  submarine  and  replenishment 
of  the  UUV,  including  re-charging  of  the  power  supply,  changes  to  the  software  package  and 
routine  software  testing  and  maintenance  actions.  Under  certain  conditions,  the  LRS  may  allow 
personnel  or  diver  access  to  the  UUV  to  support  underway  and/or  payload  changes.  The  LRS 
was  expected  to  support  multiple  launches  and  recoveries  during  a  single  deployment  cycle.  A 
graphical  illustration  of  the  operational  overview  (OV-1)  and  an  expanded  view  that  shows  the 
integration  of  the  UUV  LRS  with  the  external  boundaries  is  depicted  in  Figure  29. 
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Figure  29  -  System  Operational  Overview  (OV-1) 
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6. 


Mission  Scenarios 


a.  Launch  and  Recovery  Performance 

In  a  mission  scenario,  which  demonstrated  perfonnance  of  LRS,  the  host  submarine 
would  launch  multiple  Large  Vehicle  Class  UUVs  (up  to  3)  in  succession  while  avoiding 
detection  and  sea  traffic.  After  a  set  mission  period,  the  submarine  would  then  re-establish 
contact  with  the  UUVs  and  return  to  rendezvous  point  where  recovery  and  stowage  of  the  UUVs 
would  take  place.  Light,  average  and  severe  weather  conditions  typical  for  a  well-travelled  AO 
would  be  used  to  assess  different  version  of  this  scenario.  Measures  of  success  would  be  rapid 
launch  and  recovery  of  UUVs  with  limited  mishaps,  system  availability  and  factors  related  to 
detection  of  UUV/submarine  during  launch. 

b.  Disabled  Vehicles 

This  mission  scenario  proposed  assessment  of  retrieval  capabilities  for  Large  Vehicle 
Class  UUVs  with  various  levels  of  functionality.  In  this  scenario,  the  host  submarine  would 
arrive  a  rendezvous  point  and  attempt  to  establish  communications  with  UUVs  in  various  stages 
of  functionality  (25%,  50%,  75%  and  100%).  Returning  UUVs  communicate  with  host  ship  via 
the  LRS  and  begin  the  retrieval  process.  Measures  of  success  would  be  detennined  by  timely 
and  mishap-free  retrieval  of  UUVs  with  various  capability  limitations  (communication  systems, 
propulsion,  hovering,  and/or  structural  damage). 

c.  Replenishment  Performance 

This  mission  scenario  proposed  an  assessment  of  replenishment  of  UUV  systems  while 
stowed  in  the  LRS.  It  will  measure  the  amount  of  time  necessary  to  recharge  the  battery  system 
under  various  conditions  and  assess  the  communications  and  interfaces  between  the  UUV  and 
host  submarine  to  transfer  data.  Additionally,  the  underway  scenario  would  evaluate  the  security 
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of  the  system,  both  electronically  and  mechanically,  when  stowed.  Electronic  security  can  be 
analyzed  via  complexity  of  security  issues  and  how  data  transfer  would  occur.  Mechanical 
security  is  an  assessment  of  radiated  noise  caused  by  the  stowed  systems  and  resistance  to 
vibration  and  shock  loading.  Measures  of  success  would  include  the  timeliness  of 
replenishment  and  data  transfer  and  a  qualitative  assessment  of  noise  created  by  a  system. 
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III.  FUNCTIONAL  ANALYSIS  AND  VERIFICATION 


A.  ALLOCATE  SYSTEM  FUNCTIONS  AND  DEFINE  CONCEPTS 

1.  Background 

Following  definition  of  stakeholder  requirements,  functional  architecture  and 
mission/operational  requirements,  the  next  step  was  to  detennine  conceptual  design  alternatives 
for  the  system.  The  team  decomposed  the  stakeholder  weighted  needs  into  perfonnance 
measurements,  functions  and  component  concepts  that  reflect  the  values  of  the  project 
stakeholders.  The  result  developed  the  baseline  requirement  products  and  conceptual  design 
alternatives  that  were  used  to  accomplish  comparisons  and  analysis  in  follow-on  phases  of  the 
project. 

2.  Establish  System  Component  Concepts 

To  identify  technologies  and  component  concepts  that  could  be  integrated  and  make  up 
the  recommended  design  of  the  system,  the  team  first  sought  to  establish  and  weigh  system 
perfonnance  capabilities  and  the  system-level  functional  hierarchy.  Based  on  the  stakeholder 
requirements  and  using  the  UNTL,  literature  and  the  “standard”  Large  Vehicle  Class  UUV 
description  as  starting  points,  objectives  were  conceived  to  meet  the  requirements  and  metrics 
were  proposed  as  measurements  to  assess  the  satisfactory  performance  of  the  objectives.  Next, 
using  QFD  models,  system  performance,  function  and  conceptual  components  were  ranked 
against  the  weighted  stakeholder  requirements. 

a.  Performance  Requirements  and  Metrics 

The  Requirements  Analysis  established  the  design  criteria  to  produce  a  preferred  system, 
which  met  customer  expectations.  Initial  steps  served  to  develop  qualitative  aspects  of  the 
system,  represented  by  the  customer  requirements  or  “what”  the  customer  wants  from  the 


62 


system.  However,  to  successfully  evaluate  competing  concepts,  quantitative  aspects  of  system 
perfonnance  must  be  applied  to  each  requirement.  As  such,  evaluation  measures  were 
established  for  each  of  the  stakeholder  requirements  and  are  displayed  in  Table  5. 

For  each  requirement,  one  or  several  “objectives”  were  established.  Objectives 
represented  a  means  of  measuring  the  intent  of  a  customer  requirement.  For  instance, 
stakeholder  interviews  detennined  that  the  system  must  accommodate  large  UUV  re-chargeable 
power  sources  to  support  extended  persistent-ISR  UUV  missions.  However,  the  definition  of 
“accommodate”  in  this  context  left  multiple  integration  issues  open  for  interpretation. 
Accommodate  represented  spatial  considerations  (size,  volume)  but  also  represented  strength 
considerations  (weight,  structural  material  properties)  and  support  considerations  (energy  supply, 
transmission  of  energy).  Objectives  were  developed  to  represent  the  accommodation 
characteristics  in  measurable  ways,  identified  as  Technical  Perfonnance  Measures  (TPM). 
Evaluations  of  these  measures  were  expressed  in  terms  of  ascending  or  descending  values. 
Assignment  of  actual  values  for  performance  objectives  occurred  as  part  of  concept  development 
and  modeling  &  simulating  the  different  conceptual  design  alternatives. 
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Table  5  -  System  Performance  Objectives 


Requirement 

Objective 

Technical  Performance  Measure 
(and  Evaluation) 

Host  Submarine  Safety 

Decrease  Mishaps 

Percent  of  missions  that  result  in 
damage  to  sub  (lower  is  better) 

Resist  Shock  Damage 

Percent  of  shock  events  that 
result  in  damage  to  Grade  A 
equipment  (lower  is  better) 

Decrease  Detection 

Minutes  of  avoiding  detection  by 
enemy  in  operational  area  (higher 
is  better) 

Accommodate  Large  Power 

Needs 

Maximize  Payload  Space 

Envelope 

CUIN  of  payload  capacity 
(higher  is  better) 

Decrease  Load  on  Submarine 
Power  Supply 

Amps  required  to  re-charge  UUV 
(efficiency  of  charging  process) 
(lower  is  better) 

Maximize  Power  Transmission 
Transfer  (both  in  the  submarine 
and  while  deployed) 

Hours  to  re-charge  UUV  (lower 
is  better) 

Operational  Performance 

Decrease  Launch  Time 

Launch  time  in  minutes  (Tube 
flooded  to  UUV  underway) 

(lower  is  better) 

Decrease  Recovery  Time 

Recovery  time  in  minutes  (Local 
UUV  control  obtained  to  UUV 
stowed)  (lower  is  better) 

Maximize  Potential  Operating 
Environments 

Launch  and  recovery  capability 
in  Sea  State  Number  (higher  is 
better) 

Resist  Shock  and  Noise 

(Subset  of  Host  Submarine 

Safety  Objectives) 

Reliability 

Maximize  System  Time  to 

Failure 

Months  of  satisfactory 
performance  before  failure 
(higher  is  better) 

Affordability 

Reduce  Acquisition  Costs 

Current  Year  Dollars  (lower  is 
better) 

Reduce  Life-cycle  Costs 

Current  Year  Dollars  (lower  is 
better) 

Flexibility 

Supports  Multiple  UUV  payloads 

Number  of  significantly  different 
UUV  designs  supported  (higher 
is  better) 

Supports  Multiple  UUV  payloads 

Time  to  modify  system  (pier  side) 
to  accommodate  significantly 
different  UUV  designs  (lower) 

Weight  Control 

Reduce  Impact  on  Submarine 
Stability 

System  Center  of  Gravity  (CG)  in 
inches  (lower  is  better) 

Reduce  Impact  on  Submarine 
Weight  margin 

System  weight  in  pounds  (lower 
is  better) 

Maintainability  (Supportability) 
At-Sea 

Decrease  Turn-around 

Time  between  successful  re¬ 
launch  of  UUV  at-sea  (lower) 
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Table  5  -  System  Performance  Objectives  (Continued) 


Requirement 

Objective 

Technical  Performance  Measure 
(and  Evaluation) 

Multiple  Launch  Capabilities 

Increase  Missions 

Number  of  controlled  UUVs  in 
operational  area  simultaneously 
(higher  is  better) 

Communications 

Increase  Timeliness  ofISR 

Time  from  transmission  of 
request  to  receipt  of  information 
(lower  is  better) 

Increase  Successful  Data 
Transmissions 

Percent  of  received  and 
understood  data  transmissions 
(higher  is  better) 

(1)  Key  Performance  Parameters 

To  direct  focus  on  the  performance  measurements  considered  the  most  important  to  the 
stakeholders,  the  team  established  KPPs.  The  KPPs,  identified  in  Table  6,  each  had  an  objective 
value  (desired  goal)  and  a  threshold  value  (minimum  acceptable  performance)  established  by  the 
team  members  to  support  initial  trade-off  analysis  of  concept  designs.  Objective  and  threshold 
values  were  related  to  similar  parameters  identified  for  the  “standard”  Large  Vehicle  Class  UUV 
and  for  the  VA  Class  Block  III  submarine  design  criteria. 
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Table  6  -  Key  Performance  Parameters 


KPP 

# 

Criteria 

Objective 

Threshold 

1 

(LAUNCH  SPEED)  -  To  decrease  risk  of  detection, 
the  system  shall  minimize  launch  time  (time  from 
tube  flooded  to  time  UUV  is  away) 

1 0  Minutes 

20  Minutes 

2 

(RECOVERY  SPEED)  -  To  decrease  risk  of 
detection,  the  system  shall  minimize  recovery  time 
(time  from  UUV  manual  control  is  obtained  to  UUV 
is  stowed) 

20  Minutes 

40  Minutes 

3 

(POWER  CAPACITY  TO  UUV)  -  The  system  shall 
replenish  the  stowed  UUV  power  supply  quickly  to 
support  re-launch 

38  hrs 

50  hrs 

4 

(PAYLOAD  VOLUME)  -  The  system  shall  maximize 
payload  volume  to  support  stowage  of  multiple  UUVs 

3000  CUFT 

1000  CUFT 

5 

(COMMUNICATION  SUCCESS)  -  The  system  shall 
maximize  the  percent  and  received  and  understood 
data  transmissions. 

98%  success 
rate 

95%  success 
rate 

6 

(RELIABILITY)  -  The  system  shall  maximize  the 
Mean  Time  Between  Failure  (MTBF)  to  minimize 
maintenance  requirements. 

24  months 

1 8  months 

7 

(SAFE  OPERATIONAL  DEPTH)  -  The  system  shall 
operate  at  depth  to  avoid  detection  and  support 
mission  flexibility. 

500  feet 

150  feet 

8 

(SYSTEM  WEIGHT)  -  The  system  shall  minimize 
total  weight. 

50000  lbs 

100,000  lbs 

9 

(NOISE  PREVENTION)  -  The  system  shall  minimize 
radiated  noise,  (i.e.  supertanker  creates  ~  200  db) 

125  db 

175  db 

10 

(SHOCK  PREVENTION)  -  The  system  shall 
minimize  shock  related  damage. 

Grade  A 

Grade  B 

(2)  Ranked  Needs  to  KPPs  (QFD-1) 

To  aid  with  the  establishment  and  prioritization  of  technical  perfonnance  measures,  QFD 
models  were  utilized.  The  QFD  modeling  ensured  that  the  customer  requirements  were  reflected 
accordingly  in  the  final  LRS  design.  When  utilized,  QFD  models  established  the  system 
requirements  and  translated  them  into  technical  solutions. 

The  customer  requirements  identified  in  QFD- 1  were  weighted  by  conducting  a  pair  wise 
comparison  of  requirements.  The  results  of  the  pair  wise  comparison  can  be  found  in  Figure  10. 
In  QFD-1,  the  customer  requirements  were  ranked  according  to  design  characteristics  identified 
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as  the  LRS  KPPs  found  in  Table  6.  By  invoking  QFD-1,  the  customer  requirements  were  further 
understood  that  allowed  the  design  team  to  prioritize  the  customer  requirements  accordingly. 
With  the  prioritized  customer  requirements,  one  design  approach  was  compared  to  another  with 
each  customer  requirement  being  satisfied  with  a  technical  solution.  The  results  of  QFD-1  can 
be  seen  in  Figure  30  and  were  incorporated  into  the  QFD-2  model.  From  the  QFD  model,  it  was 


evident  that  Launch  and  Recovery  were  the  two  most  weighted  KPPs  identified  with  an  identical 
percentage  rank  of  18%. 


Design  Characteristic  (KPPs) 


Customer  Requirement  (Whats)  Weights 

Launch  Speed  * 

Recovery  Speed  * 

Power  Capacity  to  UUV  * 

Launch/Recovery  System 
Stowage  Space  * 

Information  Transfer  Rate  * 

Reliability  * 

Launch/Recovery  Depth 

Launch/Recovery  System  Weight 

Accoustic  Signature  * 

Shock 

ft/sec 

ft/sec 

$ 

to 

mb/sec 

5? 

* 

cr 

Cfl 

Q. 

cr 

Grade 

Flexible  to  accommodate  multiple  size/shape 
UUVs 

0.073 

0.073 

3 

6 

Support  multiple  packages/launches 
simultaneously 

0.052 

0.052 

3 

3 

charging 

0.123 

0.123 

9 

Lightweight 

0.072 

0.072 

9 

Affordable 

0.091 

0.091 

3 

3 

Resist  shock  and  noise  conditions 

0.102 

0.102 

9 

9 

Launch/recover  performance  parameters 
(time/stealth/moving  sub) 

0.112 

0.112 

6 

6 

6 

Reliable 

0.101 

0.101 

9 

Host  ship  safety 

0.170 

0.170 

6 

6 

3 

6 

Maintainable  at  Sea 

0.055 

0.055 

3 

3 

6 

Interface  communications 

0.050 

0.050 

9 

Check  Sum 

1.00 

Goal  Value 

Threshold  Value 

Weighted  Performance 

2.3 

2.3 

1.3 

0.4 

0.4 

1.7 

1.7 

0.6 

0.9 

0.9 

12.7 

Percent  Performance 

0.180 

0.180 

0.105 

0.034 

0.035 

0.137 

0.133 

0.051 

0.072 

0.072 

Figure  30  -  QFD-1:  Customer  Requirements  vs.  KPPs 
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b.  High  Level  Functional  Requirements 

Given  the  performance  requirements  of  the  conceptual  system,  the  team  sought  to 
describe  a  functional  description  to  the  system.  The  functional  description  explains  the  actions 
that  the  system  needs  to  take  to  reach  a  specified  objective  or  goal.  Using  the  technical 
performance  parameters  established  to  describe  the  goals  of  the  system,  the  team  established 
eight  (8)  high  level  functional  requirements  for  the  system:  execute  launch,  communicate,  system 
readiness,  obtain  environmental  information,  replenish,  secure  system,  power  UUV,  and 
maintain  system. 

(1)  Ranked  KPPs  to  Functions  (QFD-2) 

In  a  similar  fashion  to  QFD- 1 ,  a  QFD-2  was  created  to  scale  the  priority  of  design 
characteristics  to  the  high  level  functional  requirements.  The  constructed  QFD-2,  shown  on 
Figure  31,  effectively  ranked  the  importance  of  functions  in  relation  to  the  ranked  perfonnance 
derived  in  QFD-1  for  LRS  KPPs.  The  QFD-2  weighted  the  perfonnance  for  each  high  level 
function  respective  to  a  design  characteristic  KPP  and  concluded  that  Obtaining  Environmental 
Information  was  the  highest  ranked  function  with  a  weighted  percentage  of  19.8%.  Functionality 
for  Executing  Launch  and  Communicate  shared  the  second  ranking  with  a  weighted  percentage 
of  16.1%.  The  high-level  function  weighted  rankings  were  then  utilized  to  satisfy  QFD-3. 
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Functions  (Hons) 


Desian  Characteristics  fKPPs)  Weights 

Execute  Launch 

Communicate 

System  Readiness 

Obtain  Environmental 

Information 

Replenish 

Secure  Sfstem 

Power  UUV 

Maintain  System 

Execute  Recovery 

Units 

Units 

Units 

Units 

Units 

Units 

Units 

Units 

Units 

Launch  Speed  * 

0.180 

0.180 

9 

9 

6 

9 

Recovery  Speed  ’ 

0.180 

0.180 

9 

9 

6 

Power  Capacitq  to  UUV  ’ 

0.105 

0.105 

9 

Launch/Recoverq  Sqstem  Stowaqe  Space 

0.034 

0.034 

9 

Information  Transfer  Rate  ’ 

0.035 

0.035 

6 

6 

3 

6 

6 

Reliability  ‘ 

0.137 

0.137 

6 

9 

LaunchfRecoverq  Depth 

0.133 

0.133 

6 

6 

6 

Launch/Recoverq  Sqstem  Weiqht 

0.051 

0.051 

6 

Accoustic  Siqnature  ‘ 

0.072 

0.072 

6 

3 

3 

Shock 

0.072 

0.072 

6 

3 

3 

Check  Sum 

1.00 

Weighted  Performance 

Percent  Performance 

2.8 

2.6 

2.4 

3.2 

0.2 

2.6 

0.9 

1.7 

2.6 

0.139 

0.139 

0.127 

0.171 

0.011 

0.137 

0.050 

0.088 

0.139 

_ n  n 

Figure  31  -  QFD-2:  KPPs  vs.  Functions 
c.  Establish  Component  Concepts  from  Functions 

With  system  high-level  functions  established,  the  team  focused  on  the  high  level 
allocation  of  these  functions  to  system  components.  The  high-level  components  were  the 
physical  sub-systems  that  will  accomplish  the  desired  actions  of  the  system.  Although  specific 
allocation  of  functions  between  the  system  components  could  not  be  clearly  defined  without 
additional  examination  of  the  functional  architecture,  the  team  established  eight  (8)  core 
component  concepts  on  which  to  base  a  LRS  conceptual  design:  support  structure,  recovery 
mechanism,  launch  mechanism,  UUV  Power  and  Recharging  mechanism,  stowage  system, 
control  system  architecture,  RF  Spectrum  communications,  and  acoustic  communications. 


69 


(1)  Ranked  Component  Concepts  to  Functions  (QFD-3) 

Customer  requirements,  identified  in  QFD- 1 ,  were  scaled  to  system  design 
characteristics,  and  QFD-2  then  analyzed  design  characteristics  which  were  ranked  to  high  level 
functions.  QFD-3  now  used  the  weighted  performances  detennined  in  QFD-2  to  fit  forms  to 
functional  requirements.  QFD-3  ultimately  related  LRS  fonn  to  customer  requirements 
identified  in  QFD-1  and  in  Figure  32.  QFD-3  concluded  that  the  LRS  support  structure  and 
control  system  architecture  were  the  most  critical  fonns  necessary  to  satisfy  customer 
requirements  and  functionality.  Support  Structure  and  Control  System  Architecture  obtained  a 
ranking  of  33.8%  and  24.9%  respectively. 


Form  (Hows\ 


Functions  (Whats) 

Weiahts 

Support  Structure 

Recover;  Mechanism 

Launch  Mechanism 

UUV  Power  and  Re- 
Charging  Mechanism 

Stowage  Sgstem 

Control  Sgstem 
Architecture 

Radio  Frequenc; 
Communications 

Acoustic 

Communications 

Execute  Launch 

0.139 

0.139 

6 

9 

6 

Communicate 

0.139 

0.139 

3 

3 

Sqstem  Readiness 

0.127 

0.127 

3 

3 

6 

6 

Obtain  Environmental  Information 

0.171 

0.171 

6 

3 

3 

Replenish 

0.011 

0.011 

9 

3 

3 

Secure  System 

0.137 

0.137 

6 

9 

Power  (JUV 

0.050 

0.050 

9 

Maintain  System 

0.088 

0.088 

6 

Execute  Recovery 

0.139 

0.139 

6 

9 

6 

Check  Sum 

1.00 

Weighted  Performance 

2.9 

1.2 

1.2 

0  3 

2.0 

4.0 

0.9 

0.9 

14.2 

Percent  Performance 

0.202 

0.088 

0.088 

0.065 

0.143 

0.283 

0.065 

0.0651 

Figure  32  -  QFD-3:  Functions  vs.  Form 
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3.  Conceptual  Design  Alternatives 

Conceptual  design  alternatives  are  possible  physical  solutions  to  the  customers’  needs. 

For  the  LRS,  the  team  sought  to  identify  technologies  and  concepts  for  the  eight  (8)  component 
forms  established  in  the  QFD  analysis,  which  could  be  explored,  compared,  analyzed  and 
modeled.  The  conceptual  designs  established  a  starting  point  for  all  follow-on  activities  of  the 
project. 

Using  stakeholder,  SME  and  literature  input,  the  team  established  potential  technologies 
for  each  of  the  component  forms.  A  Technology  Matrix  was  established,  as  shown  in  Appendix 
B,  which  identified  the  technology,  specific  benefits  and/or  drawbacks  to  the  technology  and  the 
potential  risk  associated  with  the  technology.  Risks  were  assigned  a  value  of  high,  medium  or 
low  in  three  (3)  key  categories;  Programmatic  (Cost/Schedule),  Technology  Maturity  and 
Perceived  Performance. 

a.  Establish  Conceptual  Design  Alternatives  (Morphology) 

To  detennine  concepts  to  analyze  further,  morphology  was  used  to  detennine  every 
possible  combination  of  component  alternatives.  Initially,  due  to  the  number  of  alternatives  for 
each  of  the  eight  (8)  main  components,  morphology  generated  a  total  of  77,760  conceptual 
design  alternatives.  In  order  to  narrow  down  the  number  of  alternatives,  the  number  of  choices 
for  each  component  was  limited.  The  team  considered  more  component  choices  (up  to  3)  for 
components  that  had  a  higher  weight  in  the  QFD-3  and  limited  choices  to  1  or  2  for  the  lower- 
weighted  components.  This  methodology  reduced  the  morphology  list  to  the  top  324  design 
alternative  concepts. 

The  team  established  a  qualitative  measure  to  compare  the  remaining  alternative 
concepts.  A  numerical  value  was  assigned  to  the  remaining  components,  based  on  the  previously 
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determined  levels  of  programmatic  risk,  technological  maturity,  and  perceived  performance. 
These  values  were  used  to  calculate  the  final  score  for  each  combination  by  taking  the  sum  of  the 
component  scores  multiplied  by  the  QFD-3  weights  for  each  of  the  major  component.  Figure  33 
shows  the  top  few  lines  of  the  morphology  matrix  that  was  used  to  score  the  concepts. 
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Figure  33  -  Morphology  Matrix 

b.  Assumptions  for  Conceptual  Design  Alternatives 

Several  assumptions  were  made  by  the  Capstone  team  members  in  order  to  rank  the  eight 
(8)  main  component  combinations. 

•  Risk  rankings  for  each  component  alternative  were  correct,  based  on  team  experience, 
literature  research  and  discussion  with  peers. 

•  Identified  risk  ratings  were  used  to  narrow  down  the  number  of  alternatives  for  each 
component,  based  on  the  assumption  that  the  lower  rated  alternatives  would  not  make 
it  into  the  top  ranked  concepts. 
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•  In  scoring  the  alternatives  based  on  their  risk  ranking,  the  team  developed  a  1/3/9 
point  ranking  system  for  risk  scores  of  red,  yellow  and  green  respectively.  The  1/3/9 
point  system  has  precedence,  being  based  on  QFD  ranking  models  [Clausing,  1994, 
pg.  124],  and  was  found  to  provide  the  most  robust  differentiation  between 
alternatives. 

•  The  team  weighed  the  performance  risk  twice  as  much  as  the  programmatic  risk  and 
technical  maturity  to  align  with  stakeholder  values  and  needs  to  field  an  advanced 
concept. 

Figure  34  shows  how  the  score  was  calculated  for  each  individual  component  alternative. 
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Figure  34  -  Component  Alternative  Scores 


4.  Results,  Feasibility  and  Risks 

The  results  of  the  conceptual  design  alternative  analysis,  scoring,  ranking  and  team 
decision-making  identified  top  design  alternatives  suited  for  additional  analysis  and  comparison. 
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All  alternatives  share  several  key  components,  such  as  underwater,  short-range  radio 
communication  capabilities  and  an  acoustic  homing  communication  feature.  These 
communication  technologies  were  deemed  the  most  suitable  and  cost-effective  components 
available  to  serve  the  short-range  communications  needs  of  the  system  and  no  other  technologies 
were  considered.  Additionally,  all  alternatives  will  utilize  a  portable  plug-in  type 
hardware/software  control  system,  similar  to  systems  now  utilized  for  many  temporary 
alternations  supported  on  submarines.  Such  systems  are  easy  to  maintain  and  up-grade  when 
compared  to  hardwired  systems  as  work  can  be  done  in  a  laboratory  environment  vice  an 
industrial  facility.  However,  all  the  alternatives  did  have  significant  differences,  most  notably 
with  UUV  recovery  devices,  materials  for  the  physical  structure  and  UUV  battery  charging 
capabilities.  These  core  component  areas  address  many  of  the  challenges  and  issues  brought  up 
during  stakeholder  needs  analysis  and  provide  the  best  comparisons  between  conceptual  system 
alternatives  and  baseline  systems  that  currently  exist.  The  alternatives,  identified  in  Table  7  with 
respect  to  their  component  composition,  are  discussed  in  greater  detail  below: 
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Table  7  -  Composition  of  Concept  Alternatives 
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Baseline  -  Low  Cost  Option 

The  Baseline  Option,  considered  the  lowest  cost  option  available,  attempted  to  mirror  the 
technology  and  design  of  the  ULRM  system  built  and  tested  on  a  converted  missile  tube  of  the 
USS  FLORIDA  (SSGN  728)  during  Operation  “Giant  Shadow”.  [Galrahn,  2006]  This  option 
did  not  utilize  any  technology  to  support  UUV  recovery.  Instead,  the  baseline  option  relied  on 
the  UUV’s  ability  to  accurately  “home-in”  on  the  submarine  location  and  deployed  cradle  above 
the  VPT.  The  UUV  would  be  required  to  navigate  to  the  clamping  device  which  will  capture  the 
horizontal  UUV,  re-orient  it  to  the  vertical  position  and  stow  it  within  the  VPT.  It  was  expected 
that  the  host  submarine  would  be  nearly  stationary  to  support  UUV  recovery.  Likewise,  the 
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UUV  “swim  away”  method  of  launch  would  require  the  submarine  to  come  to  a  virtual  stop  to 
prevent  a  collision  between  the  host  sub  and  the  slow  moving  UUV. 

The  Baseline  Option  structural  composition  was  made  of  variety  of  materials  with  the 
major  portion  being  high  yield  strength  carbon  steel  (HY-80).  While  this  material  is  easy  to 
machine  or  weld,  it  is  susceptible  to  corrosion  in  a  normally  wetted  environment  and  must  be 
painted  to  prevent  oxidation.  Additionally,  as  HY-80  weighs  more  than  2x  that  of  Titanium  and 
6x  that  of  carbon  fiber  reinforced  polymers  of  equal  volume,  the  HY-80  structure  adds 
significant  weight  to  the  forward  end  of  the  VA  Class  Block  III  submarine,  which  must  be 
compensated  by  additional  ballast  aft. 

The  Baseline  Option  stowed  the  UUV  in  its  cradle  when  retracted  into  the  tube.  The 
cradle  secures  the  UUV  with  a  series  of  mechanical  locks  and  clasps  in  its  vertical  position  along 
a  series  of  guide  rails.  As  a  UUV  might  remain  in-service  for  up  to  18  months,  within  a  wet 
stowage  condition,  nonnal  and  usual  mechanical  wear  and  corrosion  of  mechanical  parts  would 
likely  create  conditions  of  gear  backlash  or  lost  motion.  The  result  could  be  a  less  secure 
stowage  of  the  20,000  lb  UUV  and  vibration  which  results  in  some  radiated  noise. 

When  developed  for  the  SSGN  missile  tube,  the  ULRM  design  leveraged  off  of  the 
existing  missile  tube  flood  and  drain  system  to  de-water  the  tube  and  support  dry  data  transfer 
and  battery  re-charging.  As  a  flood  and  drain  system  was  not  a  design  feature  of  the  VPT  for 
the  VA  Class  Block  III  submarine,  the  Baseline  Option  relied  on  cable  re-charging  of  the  battery 
in  a  wet  environment.  This  wet  environment  greatly  increased  the  risk  of  a  flooded  cable,  which 
would  jeopardize  underway  UUV  replenishment.  The  Block  IV  variant  of  the  VA  Class 
submarine  design  may  provide  a  means  to  dewater  and  access  the  VPT;  however,  this  capability 
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will  not  be  explored  in  this  project.  Figure  35  provides  a  conceptual  representation  of  the 
Baseline  Low  Cost  Option. 


Hull 


Launch/Recovery  Platform 


Figure  35  -  Baseline  (Low-Cost  Option)  Concept  Alternative 
Alternative  1-  Attraction  Recovery 

The  Attraction  Recovery  alternative  used  technologically  advanced  components  in  the 
LRS  structure  and  the  recovery  mechanism  itself  to  address  the  concerns  of  stakeholders  with 
regards  to  currently  fielded  systems.  The  key  to  this  alternative  was  an  Electro-Magnetic 
Propulsion  (EMP)  device,  which  accelerated  an  object  using  a  flowing  electrical  current  and 
magnetic  fields.  In  seawater,  such  a  device  would  charge  the  fluid  which  then  can  be  repelled. 
The  low  pressure  area  near  the  EMP  device,  caused  by  the  vacating  seawater,  would  create  a 
current  which  could  draw  the  UUV  into  a  recovery  cradle.  If  successful,  such  a  device  would 
allow  rapid  recovery  of  a  UUV  while  both  the  submarine  and  UUV  maintain  a  positive  forward 
momentum,  would  be  multi-directional  and  would  not  impose  significant  structural  stresses  on 
the  support  structure. 
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To  counter  the  stresses  put  on  the  structure  by  mechanical  launch  and  recovery  devices, 
the  proposed  structural  material  for  this  option  was  titanium.  This  material  provides  superior 
strength  and  elongation  properties  over  the  comparative  materials,  should  not  have  a  significant 
galvanic  impact  with  adjacent  materials  found  in  the  forward  end  of  the  VA  Class  Block  III 
submarine  and  should  resist  the  forces  imposed  during  launch  and  recovery.  However,  titanium 
weighs  about  3  times  as  much  by  volume  as  a  carbon  fiber  composite  material,  thereby  affecting 
submarine  stability  at  relatively  the  same  cost  per  pound. 

Other  features  found  in  this  alternative  were  a  pressurized  gas  launch  system,  found  in 
existing  missile  launch  systems,  meant  to  rapidly  deploy  the  UUV  away  from  the  host  submarine 
and  limit  collision  mishaps.  This  alternative  featured  a  dry  stowage  compartment  within  the 
VPT  where  UUV  battery  charging  and  information  transfer  can  occur  without  significant  risk  of 
electrical  shorts  or  data  disruptions.  In  the  VA  Class  Block  III  submarine  concept,  the  dry 
compartment  would  not  be  accessible  to  technicians  to  support  physical  contact  with  the  UUV 
while  underway.  However,  the  dry  compartment  would  still  provide  a  benefit  of  protecting  the 
UUV  modules  from  constant  seawater  exposure  and  corrosion/degradation  during  a  mission 
cycle,  thereby  improving  system  reliability.  Figure  36  provides  a  conceptual  representation  of 
Alternative  1. 
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Figure  36  -  Alternative  1  (Attraction  Recovery)  Concept  Alternative 


Alternative  2  -  Mechanical  Recovery  Arm 

The  Mechanical  Recovery  Arm  Alternative  utilized  an  articulated  mechanical  arm  to 
support  recovery  of  the  UUV.  This  type  of  robotic  arm  would  have  approximately  a  270°  degree 
of  motion,  with  the  VPT  hatch  preventing  full  field  recovery.  The  arm  would  be  directly 
controlled  from  inside  the  submarine  with  attached  cameras  and  sensors  providing  feedback  to 
the  operator.  Unlike  the  Attraction  Recovery  Alternative,  interaction  between  the  mechanisms 
would  require  the  UUV  to  successfully  navigate  much  closer  to  the  host  submarine,  posing  a 
greater  risk  for  collision.  Additionally,  the  UUV  and  submarine  would  likely  come  to  a  near  stop 
to  support  recovery.  However,  the  articulated  arm  design  is  currently  used  in  many  undersea 
applications  and  the  technology  has  proven  mature  and  successful. 

This  alternative  sought  to  use  a  carbon  fiber  reinforced  polymer  to  add  stiffness  and 
tensile  strength  to  the  support  structure,  at  a  weight  six  times  less  than  carbon  steel  structures  of 
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the  same  volume.  The  stiffness  of  the  carbon  fiber  structure  should  limit  vibrations  and 


consequential  radiated  noise.  It  could  be  designed  to  limit  compressive  loading  and  allow 
modular  upgrades  by  adding  or  removing  sections  via  mechanical  fasteners.  Drawbacks  of  this 
material  would  include  a  low  resistance  to  compression  and  shear  stresses  which  may  be 
countered  through  careful  design. 

The  dry  stowage  feature,  dry  power  charging  component  and  gas  launch  technology  for 

the  Mechanical  Recovery  Arm  Option  was  identical  to  that  for  the  Attraction  Recovery  Option. 

Figure  37  provides  a  conceptual  representation  of  Alternative  2. 
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Figure  37  -  Alternative  2  (Mechanical  Recovery  Arm)  Concept  Alternative 
Alternative  3  -  Remotely  Operated  Vehicle  (ROV)  Recovery 

The  ROV  Recovery  Alternative  utilized  small,  tethered,  ROVs  to  support  recovery  of  the 
UUV.  These  vehicle(s)  would  swim  out  to  meet  the  UUV,  attach  to  the  UUV  and  tow  it,  via  the 
tethered  feature,  back  into  the  VPT.  The  ROVs  would  be  controlled  from  inside  the  submarine 
with  attached  cameras  or  sensors  providing  feedback  to  the  operator.  This  recovery  option 
would  allow  capture  of  the  UUV  at  a  distance,  limiting  the  potential  for  collision  mishaps 
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between  the  UUV  and  submarine.  Additionally,  the  submarine  and  UUV  would  be  able  to 
maintain  a  forward  momentum  during  the  recovery  operation.  Although  underwater  ROVs  are 
used  in  many  operations  and  are  a  mature  technology,  such  equipment  would  itself  be  subjected 
to  possible  impact  damage,  demanding  a  redundancy  feature  at  an  extra  cost.  Furthermore, 
ROVs  are  complex  and  will  require  significant  underway  maintenance  to  ensure  the  systems 
reliability  for  the  proposed  operating  cycle. 

The  components  for  dry  stowage,  titanium  structure,  battery  re-charging  and  gas  launch 


for  the  ROVs  Recovery  Option  was  identical  to  the  components  for  the  Attraction  Recovery 


Option.  Figure  38  provides  a  conceptual  representation  of  Alternative  3. 
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Figure  38  -  Alternative  3  (ROV  Recovery)  Concept  Alternative 
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Alternative  4  -  Performance  Option 

The  Performance  Option  utilized  cutting-edge  technology  to  provide  the  most  superior 
system  for  the  stakeholder.  However,  with  performance,  programmatic  issues  such  as  cost  and 
schedule  may  be  adversely  impacted  due  to  technology  development  issues. 

Like  the  Attraction  Recovery  Option,  the  Performance  Option  will  use  an  EMP  device  to 
recover  the  UUV  at  a  distance.  Additionally,  this  option  utilized  the  same  EMP  device  to  launch 
the  UUV  simply  by  reversing  the  magnetic  field.  If  successful,  this  feature  would  support  both 
launch  and  recovery  of  UUV  at  speed  while  eliminating  the  need  for  an  additional  launching 
mechanism. 

The  Perfonnance  option  utilized  a  carbon  fiber  composite  structure  to  support  the 
equipment  necessary  for  an  electro-magnetic  suspension  stowage  system  within  the  tube.  The 
electro-magnetic  suspension  stowage  system  restrained  the  stowed  UUV  within  the  tube  without 
physical  contact.  Without  physical  contact,  the  UUV  would  be  less  prone  to  vibration  damage 
and  to  generation  of  radiated  noise.  This  option  would  require  power  and  computer-regulated 
feedback  of  the  magnetic  field  and  would  require  significant  technological  considerations  over 
mechanical  stowage  systems. 

The  battery  re-charging  component  package  on  the  Perfonnance  Option  used  inductive 
charging.  Inductive  charging  uses  an  electro-magnetic  field  to  transfer  energy  between  objects, 
in  this  case,  the  UUV  and  a  charging  pad.  Induction  chargers  use  an  induction  coil  to  create  an 
alternating  electro-magnetic  field  at  the  base  station  (charging  pad)  and  a  second  induction  coil 
in  the  portable  component  (UUV)  takes  power  from  the  electro-magnetic  field  and  converts  it 
back  into  electrical  current  to  charge  the  battery.  Charging  could  successfully  occur  in  a  wet 
environment  even  when  there  is  a  small  gap  between  the  components  and  has  a  lower  risk  of 
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electrical  shock  or  short  circuit  as  there  are  no  exposed  conductors.  Disadvantages  to  this 
technology  included  lower  efficiency  of  power  transfer  when  compared  to  conductive  charging 
and  heat  build-up  in  components.  Figure  39  provides  a  conceptual  representation  of  Alternative 
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Figure  39  -  Alternative  4  (Performance  Option)  Concept  Alternative 


a.  Feasibility  Screening 

Feasibility  screening  was  accomplished  as  an  initial  step  towards  risk  analysis  for  each 
conceptual  design  alternative.  Each  conceptual  alternative  was  evaluated  against  the  KPPs, 
identified  in  Table  6,  to  determine  if  the  concept  could  reasonably  meet  the  assigned  threshold 
values.  For  each  KPP,  a  color-coded  value  was  assigned  (Green  -  Likely  to  Meet  Objective; 
Yellow  -  Marginal  Risk  in  Meeting  Threshold;  Red  -  High  Risk  in  Meeting  Threshold).  The 
results  of  this  screening  are  contained  in  Table  8. 
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Table  8  -  Feasibility  Analysis  of  Concept  Alternatives 


KPP 

Baseline 

Alternative 

1 

Alternative 

2 

Alternative 

3 

Alternative 

4 

Launch  Speed 

L 

L 

L 

L 

Recovery  Speed 

L 

M 

L 

L 

Power  Capacity  to 

uuv 

M 

M 

M 

M 

Payload  Volume 

L 

M 

M 

M 

L 

Communications 
(Transfer  Rate) 

M 

L 

L 

L 

M 

Reliability 

L 

M 

M 

M 

M 

System  L  &  R  Depth 

M 

L 

M 

L 

L 

System  Weight 

L 

M 

L 

L 

Noise  Prevention 

M 

M 

M 

M 

L 

Shock  Prevention 

M 

M 

M 

M 

L 

Legend  - 

|  H  -  High  Risk  of  Not  Achieving  KPP  Threshold 
M  -  Moderate  Risk  of  Not  Achieving  KPP  Threshold 


L  -  Low  Risk  of  Not  Achieving  KPP  Threshold 

Feasibility  screening  in  this  context  did  not  eliminate  any  alternatives  from  consideration. 
During  the  analysis  of  potential  technologies  conducted  in  support  of  the  morphology  matrix,  the 
team  discounted  any  component  alternatives  that  placed  personnel  (divers)  in  harm’s  way  as  well 
as  component  alternatives  with  very  little  likelihood  of  success. 
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b.  Risk  Analysis  and  Mitigation  Approaches 

Risk  is  a  measure  of  future  uncertainties  in  achieving  program  performance  goals  and 
objectives  within  defined  cost,  schedule,  and  performance  constraints.  The  Risk  Management 
Process  Model,  as  described  in  the  Risk  Management  Guide  for  DoD  Acquisition  [DAU,  2006], 
consists  of  five  activities:  risk  identification,  risk  analysis,  risk  mitigation  planning,  risk 
mitigation  plan  implementation,  and  risk  tracking.  The  Project  Management  Plan,  Appendix  A, 
further  described  the  steps  taken  by  the  Capstone  team  to  identify,  analyze  and  propose  risk 
mitigation  solutions  for  the  concept  alternatives.  Mitigation  plan  implementation  proposals  and 
risk  tracking  was  recommended  at  final  concept  selection  for  potential  carry-through  into  post- 
Milestone  “A”  system  development. 

Risk  identification  and  analysis  captured  system  technical,  cost,  schedule  and 
programmatic  for  each  of  the  concept  alternatives.  Technical  risks  included  considerations  for 
perfonnance,  interfaces,  quality  of  design  and  components.  Costs  risks  included  acquisition 
considerations  such  as  Technology  Readiness  Level  (TRL)  and  development  costs  as  well  as 
long  tenn  costs  such  as  maintenance,  manpower  and  logistics  concerns.  Schedule  risks  included 
material  supply  issues  and  resource  issues,  both  in  acquisition  and  long-term  maintenance. 
Programmatic  risks  involved  a  wide  range  of  internal  and  external  concerns,  such  as  mission  and 
requirements  creep,  contractor  issues  and  sponsor/stakeholder  considerations  such  as  funding 
shortfalls.  Risks  were  identified  and  analyzed  using  the  judgment  and  experience  of  team 
members,  literature  research,  lessons  learned  from  past  system  acquisition  and  operations  and 
forecasting  of  future  events. 

Risk  consists  of  three  components:  (1)  future  risk  root  cause;  (2)  likelihood  of 
occurrence;  and  (3)  consequence  of  the  occurrence.  At  the  concept  alternative  phase  of  this 
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project,  a  qualitative  approach  to  risk  analysis  was  determined  to  be  better,  suited  as  a 
quantitative  approach  requires  specific  knowledge  with  respect  to  technologies  and  components. 
For  each  identified  risk,  a  likelihood  of  occurrence  was  assigned  and  rated  on  a  scale  of  “A”  to 
“E”.  A  rating  of  “A”  indicated  the  risk  was  “Not  Likely”  (probability  of  ~10%  occurrence) 
while  a  rating  of  “E”  indicated  the  risk  was  a  “Near  Certainty”  (probability  of  ~  90% 
occurrence).  Ratings  of  “B”,  “C”  and  “D”  confonn  to  a  probability  of  30%,  50%  and  70%, 
respectively.  Likewise,  the  consequence  that  results  from  the  occurrence  of  the  risk  was  rated  on 
a  scale  of  “1”  to  “5”  where  a  rating  of  “1”  indicated  minimal  impact  to  performance,  cost  and/or 
schedule  which  results  in  no  change  to  program  decisions  while  a  rating  of  “5”  indicates  severe 
perfonnance,  cost  and/or  schedule  impact  which  will  likely  jeopardize  the  program.  Ratings  of 
“2”,  “3”  and  “4”  designated  impacts  were  considered  minor,  moderate  and  significant, 
respectively,  to  program  parameters. 

Technical,  schedule,  performance  and  programmatic  risks  for  each  concept  alternative 
were  identified  by  root  cause  and  assessed  a  likelihood  and  consequential  severity.  If  considered 
feasible,  a  mitigation  solution  was  recommended  for  each  risk.  Table  9  provides  a  listing  of  risks 
and  the  assessment  of  the  risks  for  each  concept  alternative. 
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Table  9  -  Risk  Identification  and  Analysis  Matrix 


Concept 

Risk 

Identification 

Root  Cause  /  Rating 

Mitigation  Proposal 

Perfonnance 

Risk  1 

Risk  that  UUV  “Swim  In”  recovery 
speed  cannot  meet  KPP  /  Assessed 
as  D5 

Re-negotiate  KPP 
requirements  with 
stakeholders 

Perfonnance 

Risk  2 

Risk  that  UUV  Battery 
replenishment  components  cannot 
meet  KPP  for  replenishment  time  / 
Assessed  as  C5 

Re-negotiate  KPP 
requirements  with 
stakeholders 

Perfonnance 

Risk  3 

Risk  that  system  weight  will  not 
meet  KPP  requirements  /  Assessed 
as  C5 

Re-negotiate  KPP 
requirements  with 
stakeholders 

Baseline 

Cost  Risk 

Risk  that  choice  of  materials  (HY - 
80)  and  sliding  components  will 
result  in  more  maintenance  costs  / 
Assessed  at  C3 

Create  robust  underway 
preventative  maintenance 
program 

Schedule  Risk 

No  schedule  risks  are  anticipated 

Programmatic 
Risks  1 

Risks  that  requirements/mission 
changes  cannot  be  accommodated 
due  to  low  tech  levels  /  Assessed  at 
C3 

Implement  flexibility 
requirements  in  detailed 
design 

Programmatic 
Risks  2 

Risks  that  UUV  contractors  will 
design  a  future  concept  that  cannot 
be  accommodated  by  cradle  design  / 
Assessed  at  B3 

Limit  acceptable  design 
requirements  for  contractors 
in  baseline  design 
considerations 

Perfonnance 

Risk  1 

Risk  that  recovery  system  will  not 
generate  enough  seawater  current  to 
recover  UUV  /  Assessed  as  B5 

Increase  shipboard  power 
capabilities 

Alt  1  - 
Attraction 

Perfonnance 

Risk  2 

Risk  that  dry  seal  stowage 
compartment  will  not  work, 
impacting  battery  charging  and  data 
transfer  /  Assessed  as  A4 

Add  redundancy  to  stowage 
compartment  design 

Recovery 

Cost  Risk  1 

Risk  that  Attraction  recovery 
system  will  overrun  development 
costs  /  Assessed  as  D3 

Budget  for  technology 
development 

Cost  Risk  2 

Risk  that  titanium  structure  requires 
significant  skills  and  materials  for 
manufacture  /  Assessed  as  D3 

Conduct  early  robust 
training/stockpile  materials 
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Table  9  -  Risk  Identification  and  Analysis  Matrix  (Continued) 


Concept 

Risk 

Identification 

Root  Cause  /  Rating 

Mitigation  Proposal 

Cost  Risk  3 

Risk  that  specialized  skills  and 
materials  are  required  to  maintain 
Attraction  Recovery  mechanism  / 
Assessed  as  C3 

Stockpile  logistic 
equipment  and  conduct 
robust  training  program 
early  in  program 

Alt  1  - 
Attraction 
Recovery 
(Cont.) 

Schedule  Risk 

Risk  that  technology  development 
of  Attraction  Recovery  system 
could  delay  fielding  system  / 
Assessed  at  B2 

Program  float  into  schedule 
to  mitigate  delay  impacts 

Programmatic 

Risk  1 

Risk  that  budget  constraints  could 
reduce  funding  for  program  / 
Assessed  at  C3 

Assign  financial  roles  to 
experienced  personnel  to 
mitigate  shortfalls  /  allocate 
resources 

Programmatic 
Risks  2 

Risks  that  UUV  contractors  will 
design  future  concept  not 
accommodated  by  Attraction 
Recovery  mechanism  /  Assessed  at 
B3 

Limit  acceptable  design 
requirements  for  contractors 
in  baseline  design 
considerations 

Performance 

Risk  1 

Risk  that  mechanical  ann  will  not 
recover  the  UUV  with  system 
requirements  /  Assessed  as  C4 

Design  system  with  length, 
rapid  recovery  features 

Performance 

Risk  2 

Risk  that  dry  seal  stowage 
compartment  will  not  work, 
impacting  battery  charging  and 
data  transfer  /  Assessed  as  A  4 

Add  redundancy  to  stowage 
compartment  design 

Performance 

Risk  3 

Risk  that  composite  structure  fails 
early  under  launch  and  recovery 
operations  /  Assessed  as  B3 

Design  to  resist  shear/ 
employ  shock  absorbing 
devices 

Alt  2  - 
Mechanical 

Cost  Risk 

Risk  that  underwater  recovery  arm 
mechanism  will  overrun 
development  costs  /  Assessed  as  B3 

Budget  for  technology 
development 

Recovery 

Schedule  Risk 

Risk  that  technology  development 
of  mechanical  arm  could  delay 
fielding  system  /  Assessed  at  B2 

Program  float  into  schedule 
to  mitigate  delay  impacts 

Programmatic 
Risks  1 

Risks  that  requirements/mission 
changes  cannot  be  accommodated 
due  to  limits  of  mechanical  ann  / 
Assessed  at  B3 

Implement  flexibility 
requirements  in  detailed 
design 

Programmatic 
Risks  2 

Risks  that  UUV  contractors  will 
design  a  future  concept  that  cannot 
be  accommodated  by  mechanical 
ann  recovery  mechanism  / 

Assessed  at  B3 

Limit  acceptable  design 
requirements  for  contractors 
in  baseline  design 
considerations 
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Table  9  -  Risk  Identification  and  Analysis  Matrix  (Continued) 


Concept 

Risk 

Identification 

Root  Cause  /  Rating 

Mitigation  Proposal 

Performance 

Risk  1 

Risk  that  ROVs  recovery  will  not 
support  timely  recovery  of  UUV  / 
Assessed  as  B3 

Increase  size  and  power  of 
ROVs 

Performance 

Risk  2 

Risk  that  dry  seal  stowage 
compartment  will  not  work, 
impacting  battery  charging  and 
data  transfer  /  Assessed  as  A4 

Add  redundancy  to  stowage 
compartment  design 

Cost  Risk  1 

Risk  that  ROV  recovery  system 
will  overrun  development  costs  / 
Assessed  as  C3 

Budget  for  technology 
development 

Alt  3  - 

ROV 

Recovery 

Cost  Risk  2 

Risk  that  titanium  structure 
requires  significant  skills  and 
materials  for  manufacture  / 

Assessed  as  D3 

Conduct  early  robust 
training/stockpile  materials 

Cost  Risk  3 

Risk  that  specialized  skills  and 
materials  are  required  to  maintain 
ROV  mechanisms  /  Assessed  as  D3 

Stockpile  logistic 
equipment  and  conduct 
robust  training  program 
early  in  program 

Schedule  Risk 

Risk  that  technology  development 
of  ROV  Recovery  system  could 
delay  fielding  system  /  Assessed  at 
B2 

Program  float  into  schedule 
to  mitigate  delay  impacts 

Programmatic 

Risk 

Risk  that  budget  constraints  could 
reduce  funding  for  program  / 
Assessed  at  C3 

Assign  financial  roles  to 
experienced  personnel  to 
mitigate  shortfalls  and 
concentrate  on  resource 
allocation  to  minimize 
impacts 

Performance 

Risk  1 

Risk  that  launch/recovery  system 
will  not  generate  enough  seawater 
current  to  recover  UUV  /  Assessed 
as  B5 

Increase  shipboard  power 
capabilities 

Alt  4  - 

Perforin 

Option 

Performance 

Risk  2 

Risk  that  battery  charging  system 
will  not  have  enough  efficiency  to 
charge  UUV  timely  w/o  excessive 
heat  generation  /  Assessed  as  B2 

Design  system  to  minimize 
heat  loading 

Performance 

Risk  3 

Risk  that  composite  structure  fails 
early  under  launch  and  recovery 
operations  /  Assessed  as  B3 

Design  to  resist  shear/ 
employ  shock  absorbing 
devices 

89 


Table  9  -  Risk  Identification  and  Analysis  Matrix  (Continued) 


Concept 

Risk 

Identification 

Root  Cause  /  Rating 

Mitigation  Proposal 

Cost  Risk  1 

Risk  that  multiple  systems  will 
overrun  development  costs  / 
Assessed  as  D3 

Budget  for  technology 
development 

Alt  4  - 
Perform 
Option 
(Cont.) 

Cost  Risk  2 

Risk  that  specialized  skills  and 
materials  are  required  to  maintain 
Attraction  Device  and  battery 
charging  mechanisms  /  Assessed  as 
D3 

Stockpile  logistic 
equipment  and  conduct 
robust  training  program 
early  in  program 

Schedule  Risk 

Risk  that  technology  development 
of  multiple  systems  could  delay 
fielding  system  /  Assessed  at  C2 

Program  float  into  schedule 
to  mitigate  delay  impacts 

Programmatic 

Risk 

Risk  that  budget  constraints  could 
reduce  funding  for  program  / 
Assessed  at  C3 

Assign  financial  roles  to 
experienced  personnel  to 
mitigate  shortfalls  and 
concentrate  on  resource 
allocation  to  minimize 
impacts 

Risks  were  graphically  represented  and  compared  on  a  risk  matrix.  The  risk  matrix  was 
made  up  of  three  colors  that  denote  increasing  levels  of  risk.  The  green,  yellow  and  red  blocks 
of  the  risk  matrix  indicate  low,  medium  and  high  risks,  respectively.  To  support  the  comparison 
of  all  five  (5)  alternatives  on  one  risk  matrix,  the  technical,  schedule,  performance  and 
programmatic  risks  were  weighted  to  develop  one  average  risk  rating  for  the  concept.  Using  the 
stakeholder  requirements  and  value  system,  performance  and  costs  were  the  two  most  important 
considerations  in  fielding  a  successful  system.  Furthermore,  while  life-cycle  costs  were 
considered  important  for  all  systems,  perfonnance  issues,  particularity  UUV  recovery  and  power 
considerations  hamper  the  effectiveness  of  existing  systems.  The  following  equation  was  used  to 
develop  one  average  risk  rating  for  each  concept  alternative: 

OverallAvergeRisk  =  (4^  PR  +  2^  CR  +  ^SR  +  ^Pr  ogR)  /  #  ofRisks 
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Likelihood 


Where:  PR  is  Performance  Risk; 

CR  is  Cost  Risk; 

SR  is  Schedule  Risk; 

And  ProgR  is  Programmatic  Risk 

Table  10  provides  the  results  of  overall  risks  for  each  concept  alternative  while  Figure  40 
shows  the  comparative  risk  matrix  for  the  five  (5)  concept  alternatives. 

Table  10  -  Overall  Risk  Value  for  Each  Alternative 


Concept 

I(PR) 

I(CR) 

I(SR) 

X(ProgR) 

Final  Average 
Risk  Value 

Baseline 

C5 

C3 

NA 

C3 

C5 

Alt  1 

B4 

D3 

B2 

C3 

C3 

Alt  2 

B4 

B3 

B2 

B3 

B3 

Alt  3 

B3 

D3 

B2 

C3 

C3 

Alt  4 

B3 

D3 

C2 

C3 

C3 

Consequence 


Figure  40  -  Concept  Alternative  Risk  Matrix 
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c.  Risk  Analysis  Conclusion 

Risk  analysis  with  the  assigned  weighting  factors  found  the  best  concept  alternative  to  be 
Alternative  2,  Mechanical  Recovery  Ann.  This  system  had  a  likely  chance  of  UUV  recovery 
within  the  perfonnance  parameters  while  offering  a  system  with  lower  developmental  and  long- 
tenn  cost  risks.  System  structural  design  using  carbon  fiber  composite  materials  over  titanium 
and  steel  provided  a  significant  weight  advantage  at  a  compatible  structural  strength  assumed 
needed  for  this  system.  Cost  risks  for  carbon  fiber  structures  were  considered  negligible  as  it 
was  assumed  that  materials  will  be  purchased  and  received  in  a  completed  form  (no  molds  or 
special  skills  would  be  required  for  assembly). 

To  verify  that  weighting  method  that  favored  perfonnance  risks  over  the  other  risks  did 
not  significantly  bias  the  decision,  the  team  ran  another  set  of  calculations,  this  time  with  all  risk 
factors  equal.  These  results  found  no  change  in  the  risk  rankings  of  the  four  (4)  alternative 
options;  however,  with  the  Baseline  Option  no  longer  penalized  for  poor  perfonnance,  it  was 
now  ranked  Yellow  vice  Red.  Since  the  ranking  order  of  the  options  remained  constant  through 
two  different  weighting  options,  the  team  deemed  the  assumptions  made  that  arrived  to  the 
results  of  Table  10  a  valid  approach. 

Although  Alternative  2  was  deemed  to  be  the  least  risky,  it  was  not  significant  better  than 
Alternatives  1,  3  or  4  to  completely  discount  any  of  these  alternatives.  However,  the  Baseline 
Option  was  significantly  worse  than  all  other  options  due  to  perfonnance  concerns.  If  verified  as 
a  weak  perfonner  via  Modeling  and  Simulation,  the  Baseline  option  would  not  be  considered  the 
best  choice  with  the  given  set  of  perfonnance  KPPs. 
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B.  COST  ANALYSIS 


1.  Background 

Referring  to  the  F-35  Joint  Strike  Fighter  Program,  Defense  Secretary  Robert  Gates 
remarked  that  .  .the  nation  can  no  longer  afford  the  quixotic  pursuit  of  high-tech  perfection  that 
incurs  unacceptable  cost  and  risk. .  .’’[Scully,  2010]  In  response  to  this  and  many  other  examples 
of  uncontrolled  cost  growth  in  defense  spending,  the  Under  Secretary  of  Defense  issued  a 
memorandum  mandating  affordability  as  a  requirement  for  defense  acquisition  programs. 

[Carter,  2010]  In  this  context,  affordability  was  no  longer  viewed  as  the  cost  to  design,  build, 
test  and  field  a  weapons  system,  but  instead  is  viewed  as  the  life-cycle  cost  (LCC)  of  the  system 
which  included:  training,  interface  and  integration  with  other  systems  and  platforms,  to  absorb 
the  system  into  a  mission  area,  operational  and  support  costs,  and  disposal  costs.  To  understand 
and  compare  the  total  life-cycle  costs  of  the  five  (5)  conceptual  alternatives  in  same  year  dollars, 
the  team  perfonned  a  life-cycle  cost  analysis  to  determine  economic  equivalence.  Material 
choices  and  decisions  made  during  design  and  construction  of  the  systems  were  more  often  than 
not  the  result  in  a  false  sense  of  affordability.  Low  end  products  and  technologies,  while 
affordable  in  terms  of  acquisition  dollars  resulted  in  exponential  sustainment  costs  due  to 
premature  failures  and  the  need  for  constant  upgrades.  Likewise,  cutting  edge  equipment  might 
not  provide  its  worth  if  it  significantly  taxes  development  budgets  and  requires  modifications  to 
many  external  boundary  systems  to  work.  The  results  of  the  life-cycle  cost  analysis  were  used  as 
a  tool  during  trade-off  analysis  and  final  selection  of  the  recommended  concept. 
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2.  Methodology 

Life  cycle  cost  estimates  were  established  for  each  of  the  alternatives  identified  in  Table 
7  in  three  (3)  areas;  Acquisition,  Operations  and  Sustainment  &  Indirect  Costs.  Primarily,  cost 
estimates  were  developed  using  cost  data  from  like  vendor  sources  and  from  team  member 
experiences  in  submarine  repair,  operations  and  sustainment.  Beyond  obvious  acquisition  costs 
differences  that  result  from  using  different  materials  and  technologies,  assumptions  were 
established  to  differentiate  expected  repair  cycles  and  costs  for  each  alternative.  To  establish  a 
value  in  current  year  dollars  and  eliminate  the  effects  of  inflation,  a  real  discount  rate  of  1.7% 
was  used  for  a  system  service  life  of  20  yrs.  [OMB,  Circ.  A-94,  2010]  As  no  concept  alternative 
was  expected  to  contain  a  significant  amount  of  hazardous  materials,  disposal  costs  were  deemed 
to  be  constant  for  ah  alternatives  and,  therefore,  were  not  considered  in  a  comparison  analysis. 
Also,  since  the  system  concept  has  established  static  external  boundaries  for  the  Standard  Large 
Vehicle  Class  UUV  and  the  VPT,  ah  concept  alternatives  were  considered  equal  with  respect  to 
modifications  on  external  systems.  Finally,  a  sensitivity  analysis  was  conducted  on  high  cost 
drivers  (those  items  that  contributed  more  than  10%  to  the  overall  life-cycle  costs)  to  detennine 
how  changes  in  assumptions  affected  the  output  costs.  Variations  were  made  to  the  input 
assumptions  and  changes  were  modeled  to  help  establish  a  valid  cost  range  for  each  concept 
alternative. 

a.  Cost  Analysis  Assumptions 

To  provide  a  basis  for  cost  analysis,  the  project  team  assumed: 

•  The  UUV  LRS  would  be  fielded  and  maintained  is  a  similar  fashion  to  other  major 
submarine  support  equipment  such  as  a  SEAL  Delivery  Vehicle. 
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•  The  anticipation  is  7  VA  Class  Block  III  submarines  and  9  VA  Class  Block  IV 
submarines  with  a  VPT  would  be  fielded,  with  an  equal  number  assigned  to  the 
Atlantic  and  Pacific  fleets. 

•  As  persistent-ISR  would  be  only  one  of  many  core  submarine  missions,  no  more  than 
four  (4)  UUV  LRSs  would  be  in  use  at  any  one  time.  This  is  consistent  with  the 
employment  concept  of  VA  Class  submarines  for  SOF-type  missions. 

•  At  least  two  (2)  complete  systems  each  would  ultimately  be  fielded  on  in  the  Atlantic 
and  Pacific  areas  of  operation  beginning  in  FY+10,  when  VA  Class  Block  IV 
submarines  are  scheduled  to  be  commissioned. 

•  An  initial  increment  (INCR-1)  would  be  fielded  upon  program  inception  with  an 
improved  and  upgraded  increment  (INCR-2)  planned  for  release  to  coincide  with 
Block  IV  submarines. 

•  For  concept  alternatives  where  reliability  may  be  at  issue  (in  particular,  composite 
and  steel  structures),  at  least  one  (1)  spare  system  would  be  available  which  can  be 
transported  as  necessary  to  support  maintenance  and  repair  needs.  For  systems 
anticipated  to  require  more  maintenance  cycles,  additional  spares  would  be  required. 

•  Based  on  the  UUV  roadmap  report  of  2004,  the  useful  life  of  the  LRS  will  be 
considered  at  20  years.  Significant  technology  advances  and  mission  profiles  were 
likely  in  the  future  that  would  render  the  VPT  launched  and  recovered  UUV  obsolete 
after  20  years  of  service. 

•  In  the  20  year  life,  each  system  would  be  in-service  for  50%  of  the  time  and  awaiting 
deployment  or  in  maintenance  for  50%  of  the  time.  During  the  service  life,  each 
system  would  undergo  one  (1)  major  overhaul/modernization  period  at  the  half-life 
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and  minor/moderate  sized  overhauls  every  two  to  four  years,  depending  on  the 
assessed  reliability  of  the  system. 

•  The  cost  for  the  materials  and  labor  for  each  overhaul  were  considered  to 
approximate  submarine  maintenance  costs,  as  similar  facilities  are  expected  to 
maintain  the  systems. 

•  For  the  moderate/major  availability,  estimates  were  considered  to  be  15%  of 
acquisition  costs.  For  minor  availabilities,  estimates  were  1-3%  of  acquisition  costs. 
These  percentages  aligned  with  typical  submarine  maintenance  costs. 

•  Because  production  costs  vary  greatly  between  manufacturers  and  were  difficult  to 
reliably  estimate,  open  market  price  per  pound  of  the  different  materials  used  in  the 
support  structure  were  used  in  the  cost  analysis. 

•  To  validate  the  assumptions  of  concept  acquisition  costs,  a  comparison  was  made  to  a 
similar,  fielded  system,  the  Multiple  All-Up  Round  Canister  (MAC).  Using 
assumptions  for  MAC  material  and  labor  costs,  the  team  developed  an  estimate  close 
to  the  known  costs  of  a  MAC. 

•  By  applying  the  same  structure  and  labor  assumptions  to  the  five  (5)  concept 
alternatives,  the  obtained  acquisition  costs  were  considered  reasonable  and 
appropriate. 

3.  Life  Cycle  Cost  (LLC)  Analysis 
a.  Concept  Acquisition  Costs 

Acquisition  cost  considerations  for  conceptual  alternatives  were  established  by  using  cost 
data  from  internet  and  peer  sources  for  exact  or  similar  equipment.  Appendix  C  provides  more 
detailed  sources  and  estimates  as  to  how  the  team  arrived  at  the  cost  estimates  for  each 
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alternative.  Table  1 1  provides  the  summarized  Acquisition  Cost  analysis  for  each  concept 
alternative  on  a  per  unit  basis. 

Table  11  -  Acquisition  Costs  for  One  Unit  of  Each  Alternative  Concept 


Baseline  -  LowCost  Option 

Alternative  1  —  Attraction  Recovery 

Alternative  2  -  Mechanical  Recovery 

Technology  Option 

Cost 

Technology  Option 

Cost 

Technology  Option 

Cost 

Support  Structure 

Carbon  Steel 

s 

1,612,750 

Titanium 

$ 

12,577,750 

Composite 

$ 

5,892,000 

Recovery 

Mechanism 

“Swim  to  Cradle” 

s 

350,000 

Electro-Mechanical 

Device 

$ 

123,375 

Articulated  Mechanical 

Arm 

$ 

462,250 

Launch 

Mechanism 

“Swim  Away” 

s 

- 

Pressurized  Gas  Ejection 

$ 

660,250 

Pressurized  Gas  Ejection 

$ 

660,250 

UUV  Re-charging 

Wet  Cable  Connection, 

$ 

21,000 

Dry  Cable  Connection, 

$ 

18,425 

Dry  Cable  Connection, 

$ 

18,425 

Mechanism 

UUV  Stowed 

UUV  Stowed 

UUV  Stowed 

UUV  Stowage 
System 

Mechanical  Locks 

s 

78,000 

Sealed/ Dry 

Compartment  in  Tube 

$ 

32,550 

Sealed/Dry 

Compartment  in  Tube 

$ 

32,550 

L&R  Control 
System 
Architecture 

Portable,  Plug-in 
Control  Hardware/ 

Software 

$ 

25,855 

Portable,  Plug-in  Control 
Hardware/  Software 

$ 

25,855 

Portable,  Plug-in  Control 
Hardware/  Software 

$ 

25,855 

Short-Range  RF 
Communications 

Underwater  Radio 

Waves 

$ 

14,325 

Underwater  Radio 

Waves 

$ 

14,325 

Underwater  Radio 

Waves 

$ 

14,325 

Acoustic  Homing 
Communications 

Acoustic  Homing 
Beacon 

$ 

15,025 

Acoustic  Homing 

Beacon 

$ 

15,025 

Acoustic  Homing 

Beacon 

$ 

15,025 

Total: 

$ 

2,116,955 

Total: 

S  13,467,555 

Total: 

$ 

7,120,680 

Alternative  3  —  Remote  Vehicle 

Alternative  4  —  Performance  Option 

Technology  Option 

Cost 

Technology  Option 

Cost 

Support  Structure 

Titanium 

$ 

12,577,750 

Composite 

$ 

5,892,000 

Recovery 

Mechanism 

Tethered  Remote 
Vehicle  (ROV) 

$ 

204,250 

Electro-Mechanical 

Device 

$ 

123,375 

Launch 

Mechanism 

Pressurized  Gas 

Ejection 

$ 

660,250 

Electro-Mechanical 

Device 

$ 

172,375 

UUV  Re-charging 
Mechanism 

Dry  Cable  Connection, 
UUV  Stowed 

$ 

18,425 

Inductive  Charging 
(Touch  Pad)  UUV 
Stowed 

$ 

13,625 

UUV  Stowage 
System 

Sealed/Diy 
Compartment  in  Tube 

$ 

32,550 

Magnetic  Lock 

$ 

36,300 

L&R  Control 
System 
Architecture 

Portable,  Plug-in 
Control 

Hardware/Software 

$ 

25,855 

Portable,  Plug-in  Control 
Hardware/  Software 

$ 

25,855 

Short-Range  RF 
Communications 

Underwater  Radio 

Waves 

$ 

14,325 

Underwater  Radio 

Waves 

$ 

14,325 

Acoustic  Homing 
Communications 

Acoustic  Homing 
Beacon 

$ 

15,025 

Acoustic  Homing 

Beacon 

$ 

15,025 

Total: 

$ 

13,548,430 

Total: 

$ 

6,292,880 
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b.  Operations  and  Sustainment  Costs 

Operational  and  Sustainment  costs  were  established  for  the  fielded  conceptual  systems 
based  on  the  assumptions  provided  at  the  bottom  of  Table  12.  These  assumptions  identified  the 
number  of  LRSs  that  will  be  fielded  for  each  concept  alternative,  when  they  would  be  fielded 
with  respect  to  a  baseline  fiscal  year  (FY  BASE)  and  when  they  would  be  maintained  by  fiscal 
year.  Minor  maintenance  cycles  were  identified  as  “PM”  (Preventative  Maintenance)  with  major 
maintenance  identified  as  “OVHL”  (Overhaul)  or  Upgrade.  Time  between  maintenance  was 
assigned  by  team  members  based  on  existing  submarine  operating  cycles  and  the  degree  of 
maintenance  considered  necessary  for  the  different  types  of  components.  Neither  Disposal  nor 
Salvage  costs  were  considered  as  ah  concept  alternatives  were  considered  to  be  identical  in  these 
respects. 

As  costs  for  each  alternative  concept  provided  in  Table  12  were  identified  in  future  year 
dollars,  standardization  was  conducted  to  determine  single  dollar  value  costs  for  each  concept 
alternative  in  present  year  dollars.  Using  OMB  Circular  A-94,  a  discount  factor  of  1.7%  was 
applied  to  give  the  present  year  dollar  costs,  as  given  in  Table  13. 
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Table  12  -  Operations  and  Sustainment  Costs  for  Life  Cycle  of  each  Alternative  w/o 

Present  Value  Discount  Factors  Applied 


(1)  3  units  bought  for  IX’CR  1  and  3  additional  units  bought  for  IX'C'R  2 

(2)  2  units  bought  for  IXCR  1  and  2  additional  units  bought  for  IX'C'R  2 

(3)  2  units  bought  for  IXCR  1  and  3  additional  units  bought  for  IXCR  2 

(4)  Baseline  unit  get  PM  (2°c  Acq)  every  24M  and  OVKL  (15°o  Acq)  every  3rd  maintenance  action 

(5)  Alls  unit  get  PM  (2°c  Acq)  every  36M 

(6)  IXCR  1  units  get  upgrade  at  10  years  (S2M  Unit  for  Baseline.  SIM  Unit  for  ALTs) 

(7)  Initial  capital  outlay  of  S4M  for  carbon  fiber  molds 


Table  13  -  Operations  and  Sustainment  Costs  for  Life  Cycle  of  each  Alternative  with 

Present  Value  Discount  Factors  Applied 


Calculate  Xet  Present  Value  in  Current  Year  Dollars  (l.~  Jc  Discount  Rate  per  OUB  A-94,  Dec.  2010  for  20  yrlifej 


Acq- 

IXCR1 

PM 

PM 

PM 

Ovhl 

PM 

PM 

PM 

Acq- 

IXCR2 

Upgrade 

PM 

PM 

PM 

Ovhl 

PM 

PM 

PM 

In  Present 

Yr  Dollars 
($M) 

Alternative 

FY  Base 

FY-2 

FY-3 

FY-4 

FY-6 

FY-S 

FY+9 

FY-10 

FY-10 

FY-12 

FY-13 

FY-14 

FY— 16 

FY-1S 

FY-19 

Baseline 

6.9 

0.135 

0.131 

0.94 

0.122 

5.S2961 

5.069226S 

0229 

0221 

’  1.5SS 

0207 

21.4 

ALT-1 

27.4 

0.523 

0.497 

0.473 

23.1495 

1.6S9"423 

0.8S4 

0.S4 

0799 

56.3 

ALT-2 

1S.S 

02S5 

0271 

025S 

18.7561 

1.6897423 

0.594 

0.565 

0.537 

41.8 

ALT-3 

27.6 

0.523 

0.497 

0.473 

23.3 1S4 

1.6S97123 

0.SS4 

0.S4 

0799 

56.6 

ALT-4 

17 

0247 

0235 

0223 

16.475 

1.689U23 

0.522 

0.496 

0.472 

37.4 

c.  Indirect  Costs 

Due  to  different  manufacturing  processes  between  metallic  (carbon  steel  and  titanium) 
structures  and  composite  (carbon  fiber)  structures,  manufacturing  costs  were  examined.  Each 
metallic  structure  requires  forming,  machining,  welding  and  non-destructive  testing  of  the  raw 
materials  to  create  the  final  cylindrical  structure.  Although  process  improvements  and 
“learning”  may  improve  the  manufacture  process  over  the  long  run,  the  relatively  small  overall 
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number  of  units  required  in  a  single  fiscal  year  was  considered  to  cancel  out  any  long-term  cost 
benefits  in  manufacturing.  As  shown  in  Appendix  C  tables,  labor  costs  to  manufacture  each 
metallic  structure  were  considered  static  and,  based  on  similar  work  perfonned  in  public 
shipyards,  estimated  to  take  250  Man  Days  at  a  labor  rate  of  $680/Man  Day,  or  $  170K  per 
structure. 

Composite  (carbon  fiber)  structures  require  molds  and  manufacturing  processes  such  as 
compressive  molding,  to  fabricate  the  parts  necessary  to  create  the  structure.  Molds  for  the 
compressive  molding  process  are  typically  manufactured  from  a  lightweight  metal,  such  as 
aluminum,  and  are  reusable.  Initial  manufacturing  costs  for  the  molds  must  be  considered  in  the 
overall  life-cycle  costs  of  composite  structures. 

The  cylindrical  structure  for  the  LRS  would  be  designed  for  simplicity  and  uniformity 
throughout,  using  various  circular  and  truss  segments  which  would  be  mechanically  fastened 
together.  The  Capstone  team  estimated  that  twenty  (20)  separate  molds  would  be  required  to 
fabricate  the  composite  structure.  Using  a  known  price  of  $7.5K  for  4’  x  12’  x  2”  aluminum 
plate  and  an  estimated  volume  of  1500  in3  per  mold,  the  raw  material  costs  for  the  molds  was 
estimated  at  $600K.  Using  machining,  tooling,  maintenance,  rental  of  presses  and  profit 
estimates  of  250  Man  Days  per  mold  at  a  labor  rate  of  $680/Man  Day,  the  cost  per  mold  equated 
to  $170K.  Therefore,  the  total  estimated  cost  to  manufacture,  maintain  and  use  the  molds  was 
$4M.  This  capital  outlay  cost  was  added  to  the  carbon  fiber  alternatives  when  detennining  life- 
cycle  costs. 

After  accounting  for  the  initial  costs  of  molds,  the  Capstone  team  detennined  that 
fabrication  costs  for  the  carbon  fiber  structures  were  comparable  to  fabrication  costs  for  metallic 
structures.  Preparation  times  and  compression  times  for  the  molding  process  are  similar  to 
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forming,  machining  and  welding  times  for  metallic  structures.  Both  processes  require  skilled 
mechanics.  Assembly  times  for  carbon  fiber  structures  were  considered  negligible.  As  such, 
manufacture  of  each  carbon  fiber  structure  was  estimated  to  take  250  Man  Days  at  a  labor  rate  of 
$680/Man  Day,  or  $170K  per  structure. 

All  other  indirect  costs  such  as  training,  specifications,  facilities,  and  other  logistical 
concerns  were  not  specifically  discussed  above  nor  broken  out  as  these  costs  were  not  considered 
significantly  different  for  any  of  the  alternatives.  However,  these  costs  were  factored  in  and 
considered  when  preparing  the  costs  for  engineering,  design,  program  management,  material, 
and  spare  parts.  The  worksheets  for  all  related  cost  estimates  are  provided  in  Appendix  C  -  Cost 
Analysis  Worksheets. 

4.  Cost  Sensitivity  Analysis 
Titanium  Discussion 

Much  of  the  titanium  produced  today  goes  into  the  manufacture  of  aircraft  engine  parts 
and  structural  components.  Titanium  dioxide  is  used  in  paints,  paper  and  plastics  and  other 
products.  Titanium  has  also  become  indispensible  in  the  marine  industry  because  of  it  corrosion 
resistant  properties  in  saltwater.  Wall  thickness  of  titanium  structural  components  may  be 
reduced  because  of  superior  strength  qualities  and  corrosion  allowance.  It  is  difficult  to  predict 
future  prices  of  titanium  but,  based  on  current  supply  and  anticipated  demand,  prices  will  likely 
increase  in  the  future  as  China  and  India  increases  industrial  demand  for  titanium  materials. 
Figure  41  shows  historical  prices  since  2005  that  show  a  downward  trend  in  price  from  2005  to 
2009  as  the  United  States  eliminated  the  remaining  strategic  Cold  War  government  stockpiles 
[Seong,  2009].  The  current  price  of  titanium  raw  material  bars  and  plates  is  approximately  $7/lb 
and  has  increased  slightly  since  2009. 
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Historical  prices  sourced  from  www.metalprices.com 

Figure  41  -  Cost  Comparisons  Showing  Varying  Titanium  Prices 

The  costs  of  the  two  alternatives  containing  titanium  were  approximately  $13.5M,  almost 
twice  the  next  lower  cost  alternative  that  used  a  carbon  fiber  composite  structure  and  six  times 
the  cost  of  the  carbon  steel  alternative.  A  continued  upward  trend  of  price  would  likely  make  the 
titanium  option  much  less  appealing.  Table  14  below  provides  a  comparison  of  ALT-3  with 
varying  costs  of  titanium  and  the  differences  from  the  lower  cost  alternatives.  The  current 
differences  in  cost  of  the  lower  cost  options  are  significant  and  if  the  cost  of  titanium  rises,  the 
cost  gap  becomes  increasingly  excessive. 


Table  14  -  Cost  Differences  of  ALT-3  with  Baseline  and  ALT-4  Configurations 


Titanium 

$/Ib 

ALT  -  3 
(with  varying 
titanium  costs) 

Cost  Difference 

from  Baseline 

Cost  Difference 

from  ALT-4 

$ 

8 

$  14,733,945 

$  12,616,990 

$  8,441,065 

$ 

10 

$  18,174,762 

$  16,057,807 

$  11,881,882 

$ 

11 

$  19,895,170 

$  17,778,215 

$  13,602,290 

$ 

14 

$  25,056,394 

$  22,939,439 

$  18,763,514 

$ 

19 

$  33,658,435 

$  31,541,480 

$  27,365,555 
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Carbon  fiber  composite  is  a  strong,  lightweight  material  that  is  at  least  five  times  as 
strong  as  steel  and  weighs  about  two-thirds  less.  Carbon  fiber  composite  is  composed  of  very 
thin  strands  of  carbon,  which  are  twisted  and  woven  together  and  then  laid  over  a  mold  and 
coated  with  resin  to  fonn  a  permanent  shape.  Carbon  fiber  composite  technology  has  become  a 
viable  alternative  material  in  the  last  fifteen  years  due  to  the  raw  material  price  per  pound  drop 
from  around  $150  to  about  $8  -  $10.  [Zoltec,  2011]  As  more  industries  explore  the  use  of  carbon 
fiber  composites  in  their  products,  the  price  per  pound  should  remain  relatively  stable  if  not 
decline.  The  analysis  for  the  LRS  Carbon  Fiber  Support  Structure  was  based  on  a  raw  material 
cost  of  $8/lb,  which  resulted  in  an  approximate  $9M  total  cost  for  the  first  unit  (factoring  in  $2M 
capital  costs  for  manufacture  of  molds)  and  approximately  $7M  for  each  successive  unit.  Table 
15  compares  the  differences  in  varying  Carbon  Fiber  price  per  pound  against  the  baseline 
alternative  cost.  Currently  the  raw  material  cost  of  $8/lb  is  roughly  twice  the  baseline  alternative 
cost.  As  the  price  per  pound  comes  down,  the  cost  difference  becomes  more  of  a  desirable 
alternative. 

When  comparing  the  cost  of  Carbon  Fiber  against  Alternative  3  (Titanium  Option), 
Carbon  Fiber  is  already  a  preferred  choice  when  only  considering  cost.  Table  16  compares  the 
cost  of  Alternative  3  using  Carbon  Fiber  vice  Titanium  for  the  support  structure.  The  cost 
difference  at  the  current  raw  material  $8/lb  estimate  of  carbon  fiber  material  is  $7.7M.  This 
difference  becomes  significantly  larger  if  the  cost  of  carbon  fiber  composite  comes  down.  The 
future  trend  for  carbon  fiber  demand  is  expected  to  increase  at  a  constant  rate  through  2013 
[Zoltec,  2011]  which  could  mean  that  lower  costs  are  realized. 
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Table  15  -  Cost  Differences  of  ALT-4  with  Baseline  Configuration 


Carbon 

Fiber 

$/lb 

ALT-4 

(with  va ryi ng 

ca rbon  fi ber 

costs ) 

Cost  Difference 

from  Baseline 

$ 

4 

$  3,119,247 

$ 

1,002,292 

$ 

6 

$  4,478,431 

$ 

2,361,476 

$ 

8 

$  5,837,615 

$ 

3,720,660 

$ 

10 

$  7,196,798 

$ 

5,079,843 

$ 

14 

$  9,915,166 

$ 

7,798,211 

Table  16  -  Cost  Differences  of  ALT-4  with  ALT-3  Configuration 


Carbon 

Fiber 

S/lb 

ALT-4 

(with  varying 
carbon  fiber 
costs) 

Cost  Difference 

from  ALT-3 

$ 

4 

$  3,119,247 

$ 

10,429,183 

$ 

6 

$  4,478,431 

$ 

9,069,999 

$ 

8 

$  5,837,615 

$ 

7,710,815 

$ 

10 

$  7,196,798 

$ 

6,351,632 

$ 

14 

$  9,915,166 

$ 

3,633,264 
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5. 


Cost  Analysis  Results 


Table  17  provides  a  summary  of  total  costs  for  operations  and  sustainment  for  a  life  cycle 
of  each  alternative  configuration  analyzed.  Because  of  anticipated  reliability  differences  for  each 
alternative,  the  alternatives  that  used  superior  structural  materials  would  require  fewer  LRS  units. 
Currently,  the  plan  was  for  there  to  be  two  units  for  the  east  coast  and  two  units  for  the  west 
coast  available  at  any  time.  Of  the  alternatives,  titanium  was  considered  the  superior  material; 
therefore,  our  acquisition  plan  is  to  purchase  a  total  of  only  four  units  over  two  increments  to 
accommodate  the  plan  for  two  units  on  each  coast.  ALT-1  &  ALT-3  both  use  titanium  for  the 
structure.  Total  cost  for  ALT-1  which  included  life  cycle  costs  is  $56.3  M  and  ALT-3  is  $56. 6M. 
These  were  the  highest  cost  alternatives  even  with  only  acquiring  four  total  units  mainly  because 
of  the  high  costs  of  titanium  used  in  the  support  structure. 

ALT-2  and  ALT-4  were  the  next  highest  cost  alternatives  and  are  composed  of  carbon 
fiber  composite  for  the  support  structure.  The  acquisition  plans  for  these  alternatives  included 
the  purchase  of  five  total  units,  two  units  at  increment  one  and  an  additional  three  at  increment 
two.  The  additional  unit  accounted  for  possible  reduction  in  perfonnance  of  one  of  the  original 
units.  Total  costs  for  ALT-2  were  $41.8M  and  ALT-4  $37.4M. 

The  baseline  alternative  was  the  lowest  cost  alternative  even  with  the  acquisition  of  six 
units  which  are  required  because  of  the  inferior  carbon  steel  material  has  a  lower  anticipated 
reliability.  The  total  costs  for  baseline  alternative  is  $21.4M.  If  costs  were  the  only  factor 
considered,  the  baseline  alternative  would  be  the  natural  recommendation  since  it  is  at  least  50% 
less  than  the  next  higher  alternative  cost.  But  total  cost  would  not  be  the  only  factor  and  will  be 
part  of  the  larger  decision-making  process  to  arrive  at  a  recommended  solution. 
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Table  17  -  Total  Life-Cycle  Costs  for  Each  Conceptual  Alternative 


Alternative 

In  Present  Yr 
Dollars  ($M) 

Baseline 

21.4 

ALT-1 

56.3 

ALT-2 

41.8 

ALT-3 

56.6 

ALT-4 

37.4 

C.  PERFORMANCE  MODELING  AND  SIMULATION 

1.  Background 

The  baseline  and  four  concept  alternatives  identified  in  Table  7  where  modeled  using  a 
simulation  software  package  known  as  ExtendSIM®.  Modeling  captured  the  perfonnance  of 
each  alternative’s  four  primary  functions:  Launch,  Recovery,  Maintain  and  Replenish.  The 
ExtendSIM®  modeling  provided  a  means  to  evaluate  each  concept’s  anticipated  behavior  in 
operational  conditions.  Modeling  parameters  are  unique  for  each  concept  alternative  and  were 
derived  by  evaluating  the  component  composition  of  each  alternative. 

To  construct  the  models  and  simulate  operational  conditions  it  was  necessary  to  define 
various  assumptions  for  operation.  The  weather  assumptions  in  Table  18  were  applied  for 
launch  and  recovery  models  and  were  held  constant  for  all  simulation  runs.  When  considering 
success  for  launch  or  recovery  it  was  defined  as  the  ability  to  launch  or  recover  a  UUV  without 
being  detected  by  a  threat  and  without  damaging  the  host  platfonn,  UUV  or  LRS.  Being 
detected  or  causing  any  damage  was  considered  a  failed  launch. 
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Table  18  -  Weather  Condition  Likelihood 


Weather 

Probabilities 

Fair 

85% 

Moderate 

10% 

Poor 

5% 

2.  Evaluation  Measures  for  Concept  Alternatives 

Each  of  the  four  models,  Launch,  Recovery,  Maintain  and  Replenish  were  simulated 
1000  times,  creating  a  database  to  assess  the  performance  of  each  concept  alternative.  The 
concept  alternative  parameters  identified  in  Table  19  were  derived  from  subjective  evaluation  of 
the  components  expressed  in  Table  7  using  technical  knowledge  of  the  team  members  and  their 
experiences  with  the  various  technologies.  When  reasonable  comparisons  could  be  made  by  the 
team,  rationale  for  the  choices  and  tolerances  are  provided  in  Table  19  Notes. 
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Table  19  -  Concept  Alternative  Modeling  Parameters 


Modeling  Parameters 

Parameter 

Baseline 

Alt  1 

Alt  2 

Alt  3 

Alt  4 

Launch  duration 
[minutes] 1 

15±2.5 

1 1.25±2.5 

1 1.25±2.5 

1 1.25±2.5 

12.75±2.5 

Recovery  duration 
[minutes]2 

37.5±3.0 

25.5±3.0 

30.0±3.0 

27.0±3.0 

25.5±3.0 

Successful 

Launch/Recovery3’ 

6 

92.00% 

96.00% 

94.00% 

95.00% 

96.00% 

Communication 

Success 

98.50% 

98.90% 

99.50% 

99.00% 

98.00% 

Reliability7 

96.80% 

98.00% 

97.30% 

98.40% 

98.40% 

Diagnostic 

Success 

98.50% 

98.50% 

98.50% 

98.50% 

98.50% 

System 

Reconfiguration 

Success 

98.90% 

98.90% 

98.90% 

98.90% 

98.90% 

Mission  Upload 
Success 

99.00% 

99.00% 

99.00% 

99.00% 

99.00% 

Recharging 

Success 

99.00% 

98.00% 

98.00% 

98.00% 

97.00% 

Replenishment 
Duration  [hours]4 

45.6±5.7 

45.54±0.66 

45.54±0.66 

45.54±0.66 

43.71±1.89 

Maintain 

Positioning 

Success 

99.00% 

99.00% 

99.00% 

99.00% 

99.00% 

UUV  Successful 
Secured 

99.00% 

99.50% 

99.50% 

99.50% 

99.20% 

ISR  Data 

Download 

Successful 

99.80% 

99.80% 

99.80% 

99.80% 

99.80% 

Maintain  Duration 
[minutes] 

15.0±2.5 

12.0±3.0 

12.0±3.0 

12.0±3.0 

1 1.0±2.5 

Overall  Total 

Cycle  Time 
[hours]5 

46.73 

46.35 

46.35 

46.35 

44.53 
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Table  19  Notes 

(1)  Based  on  average  time  to  load  mission/launch  VLS  Weapon,  SSN  688  Class.  Weighting 
factors  consider  speed  at  which  launch  method  allows  UUV  to  “clear”  submarine  envelope. 

(2)  Based  on  average  time  to  load  mission/launch  VLS  Weapon,  SSN  688  Class  (time  is  doubled 
as  a  baseline  for  recovery).  Weighting  factors  include  distance  required  to  recover  and  if 
recovery  equipment  can  operate  in  a  360°  field  vice  limited  direction. 

(3)  Based  on  success  of  torpedo  test  launches  for  SSN  688  Class.  Does  not  account  for  UUV 
failure  or  system  reliability  (covered  elsewhere).  Weighting  factors  considers  speed, 
movement  of  submarine,  autonomy  of  launch/recovery  (navigation  error  of  UUV). 

(4)  Objective  charging  time  assumes  500kWh  charge  required  (energy  capacity  for  the 
“Standard”  Large  Vehicle  Class  UUV)  using  largest  available  submarine  source  (440  VAC, 
30  Amps).  For  wet  conductive  charge,  assume  95%  efficiency  plus  factor  for  corrosion 
damage,  water  leakage.  For  dry  charge,  assume  6  hours  to  dry  stowage  compartment  and 
95%  to  98%  efficiency.  For  wet  inductive  charging,  assume  80%  to  90%  efficiency. 

(5)  Based  on  A0  factor  for  a  SSN  688  Class  Torpedo  Tube  Launch  System.  Weighing  factors 
consider  the  complexity  of  the  technology  and  environment  (wet  vs.  dry). 

(6)  Factor  of  noise  at  launch/recovery,  speed  of  launch  recovery,  security  of  equipment  when 
stowed. 

(7)  Measures  robustness  of  the  equipment.  The  likelihood  of  failure  per  1000  cycles.  Increased 
moving  parts,  system  complexity  and  corrosion  of  carbon  steel  would  negatively  affect 
system.  Carbon  fiber  is  more  prone  to  shear  stress  damage  and  impact  damage.  Titanium 
would  offer  corrosion  resistance  and  reduction  in  weight  with  significant  strength 
advantages.  A  gas  launch  system  creates  additional  stresses  which  could  potentially  induce 
component  failure.  Redundancy  of  ROV  is  advantageous.  Single  point  failures  are  bad 
(technology  that  requires  excessive  power,  failure  to  dry  the  stowage  compartment,  etc). 

3.  Model  Descriptions  and  Results 
a.  Model  Description 

To  provide  a  realistic  and  germane  mission  scenario  to  the  model,  Operational  Situation 

No.  1  (OPSIT  #1)  proposed  the  use  of  the  submarine  launched  Large  Vehicle  Class  UUVs  to 

counter  efforts  by  a  foreign  power  to  choke  off  oil  exports  through  a  geographically  critical  area 

such  as  the  Strait  of  Hormuz.  Figure  42  provides  a  visual  depiction  of  the  Strait  of  Hormuz. 
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Figure  42  -  Depiction  of  Strait  of  Hormuz 

At  its  narrowest  point,  the  Strait  of  Hormuz  is  21  miles  wide,  and  the  shipping  lanes 
consist  of  two-mile  wide  channels  for  inbound  and  outbound  tanker  traffic,  as  well  as  a  two-mile 
wide  buffer  zone.  The  majority  of  oil  exported  through  the  Strait  of  Hormuz  travels  to  Asia,  the 
United  States  and  Western  Europe.  In  2007,  an  average  of  15  crude  oil  tankers  passed  through 
the  Strait  of  Hormuz  daily,  along  with  tankers  carrying  other  petroleum  products  and  liquefied 
natural  gas  (LNG). 

Foreign  action  to  block  transit  though  this  area  would  result  in  oil  shortages,  increase  the 
price  of  oil  and  potentially  lead  to  world-wide  financial  crisis.  Foreign  governments  in  this  area 
of  the  world  have  been  unstable  and  consistently  have  taken  an  adversarial  posture  towards 
United  States  interests.  Persistent-ISR  missions  by  multiple  UUYs  in  this  high  sea  traffic  area 
would  enable  US  and  allied  Intelligence  interests  to  react  quickly  to  challenges  by  an  enemy 
force  with  minimal  risk  to  US  submarines.  Success  of  this  mission  requires  the  success  of  all 
four  functions:  Faunch,  Recovery,  Maintain  and  Replenish.  Failure  to  satisfy  all  four  functions 
would  compromise  the  OPSIT. 
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b.  Modeling  and  Simulation  Results 

All  four  functions,  Launch,  Recovery,  Maintain  and  Replenish,  were  successfully 
modeled  using  the  parameters  specified  per  Table  19.  The  ExtendSIM®  models  used  for 
simulation  can  be  found  in  Appendix  D.  Data  derived  from  each  of  the  models  was  analyzed 
with  descriptive  statistics  to  evaluate  the  performance  of  each  alternative.  The  raw  data  from 
each  model  can  be  found  in  its  respective  section  of  Appendix  D.  The  critical  performance 
results  of  concern  were  the  likelihood  of  success  for  each  of  the  four  functions  and  their  average 
operational  time  as  reported  per  Table  20.  The  concept  alternatives  where  then  ranked  in 
accordance  to  performance  from  best  to  worst  in  Table  21. 

In  respect  to  OPSIT  #1,  mission  success  was  defined  as  the  success  of  all  four  functions: 
Launch,  Recovery,  Maintain  and  Replenish.  When  evaluating  the  results,  a  concept  alternative 
can  only  be  as  successful  as  the  system’s  reliability  to  successfully  perform  all  four  functions 
when  pertaining  to  OPSIT  #1.  The  likelihood  of  success  for  OPSIT  #1  and  the  total  operational 
time  for  each  alternative  is  identified  in  Table  20. 


Table  20  -  Model  Simulation  Results 


Launch 

Recovery 

Maintain 

Replenish 

OPSIT#l 

Success 

Time 

|min] 

Success 

Time 

[min] 

Success 

Time 

[min] 

Success 

Time 

[hr] 

System 

Reliabi 

lity 

Time 

[min] 

Baseline 

81.50% 

14.97 

81.00% 

37.45 

96.70% 

15.07 

93.60% 

45.56 

59.75% 

2801.09 

Alt  1 

90.30% 

11.25 

88.70% 

25.63 

96.80% 

12.04 

93.00% 

45.55 

72.11% 

2781.92 

Alt  2 

85.40% 

11.25 

86.60% 

30.05 

98.20% 

11.99 

94.30% 

45.54 

68.49% 

2785.69 

Alt  3 

89.40% 

11.33 

87.70% 

26.95 

97.10% 

12.22 

92.40% 

45.55 

70.34% 

2783.5 

Alt  4 

90.10% 

12.84 

87.20% 

25.47 

96.10% 

10.98 

91.10% 

43.7 

68.78% 

2671.29 
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Table  21  -  Ranked  Alternative  Performance 


Launch 

Recovery 

Maintain 

Replenish 

OPSIT#l 

Success 

Time 

Success 

Time 

Success 

Time 

Success 

Time 

System 

Reliability 

Time 

Best 

Alt  1 

Alt  1 

Alt  1 

Alt  4 

Alt  2 

Alt  4 

Alt  1 

Alt  4 

Alt  1 

Alt  4 

4 

Alt  4 

Alt  2 

Alt  3 

Alt  1 

Alt  3 

Alt  2 

Alt  4 

Alt  2 

Alt  3 

Alt  1 

3 

Alt  3 

Alt  3 

Alt  4 

Alt  3 

Alt  1 

Alt  1 

Alt  3 

Alt  1 

Alt  4 

Alt  3 

2 

Alt  2 

Alt  4 

Alt  2 

Alt  2 

Base 

Alt  3 

Alt  2 

Alt  3 

Alt  2 

Alt  2 

Worst 

Base 

Base 

Base 

Base 

Alt  4 

Base 

Base 

Base 

Base 

Base 

After  review  and  analysis  of  the  model  simulation  results  of  Table  20  it  was  observed  that 
all  concept  alternatives  significantly  outperfonned  the  baseline,  which  only  resulted  in  a  system 
reliability  of  59.75%,  compared  to  the  more  advanced  alternatives,  whose  reliabilities  ranged 
from  68.49%  to  72. 11%.  The  overall  time  to  complete  all  four  functions,  Launch,  Recover, 
Maintain  and  Replenish  were  negligible  between  the  baseline  and  alternative  LRS  designs  with 
times  ranging  from  267 1  minutes  to  2801  minutes.  This  was  due  to  the  relatively  similar  time 
required  to  successfully  refuel  the  UUV  which  was  grossly  more  time  consuming  in  comparison 
to  the  time  it  took  to  complete  launch,  recovery  or  maintain  functions, 
c.  Model  and  Simulation  Conclusion 

In  an  evaluation  the  model  results  on  a  purely  performance  perspective  Table  21  ranked 
the  baseline  and  all  concept  alternatives  from  best  functional  performance  to  worst  functional 
performance.  Alternative- 1  proved  to  be  the  most  reliable,  72. 11%,  while  Alternative-4  proved 
to  have  the  best  time  performance  completing  all  functions  in  a  total  of  267 1  minutes. 
Alternatives  1  and  4  dominated  Alternatives  2,  3  and  Baseline  when  compared  to  reliability  and 
time  performance  per  OPSIT  #1  and,  as  such,  from  a  perfonnance  standpoint,  are  considered  the 
superior  alternatives.  However,  without  additional  knowledge  of  the  stakeholder  value  system  or 
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a  weighting  associated  with  reliability  or  speed,  no  single  alternative  was  be  down-selected 
purely  on  performance. 

d.  Launch  &  Recovery  Sensitivity  Analysis 

A  sensitivity  analysis  evaluated  the  baseline  and  design  concepts  sensitivity  to  variation 
in  LRS  component  success  and  its  effect  on  a  successful  launch  and  recovery.  Simulations  were 
conducted  on  all  design  models  identified  in  Appendix  D,  varying  the  LRS  reliability  parameter 
by  5%,  10%  and  15%.  The  simulations  were  successfully  perfonned  and  the  results  are 
identified  in  Table  22. 


Table  22  -  Launch  &  Recovery  Sensitivity 


Launch 

Recovery 

LRS 

Reliability 

Variable 

LRS 

Component 

Success 

Launch 

Success 

Sensitivity 

Launch/ 

Component 

Success 

LRS 

Component 

Success 

Recovery 

Success 

Sensitivity 

Recovery/ 

Component 

Success 

Alt  1 

98.00% 

98.40% 

90.30% 

0.90 

98.00% 

88.70% 

0.89 

93.00% 

91.90% 

84.90% 

92.40% 

83.10% 

88.00% 

87.10% 

80.90% 

88.60% 

79.80% 

83.00% 

81.60% 

75.00% 

84.10% 

76.40% 

Alt  2 

97.33% 

97.20% 

85.40% 

0.86 

97.40% 

86.60% 

0.94 

92.33% 

91.40% 

81.10% 

93.70% 

82.50% 

87.33% 

87.00% 

76.40% 

87.80% 

76.30% 

82.33% 

81.00% 

71.70% 

81.60% 

71.80% 

Alt  3 

98.40% 

99.20% 

89.40% 

0.76 

98.60% 

87.70% 

0.89 

93.40% 

93.40% 

82.80% 

93.00% 

84.70% 

88.40% 

87.10% 

79.50% 

91.10% 

81.20% 

83.40% 

82.10% 

76.00% 

82.40% 

73.70% 

Alt  4 

98.40% 

98.00% 

90.10% 

0.95 

98.50% 

87.20% 

0.79 

93.40% 

94.10% 

87.00% 

94.10% 

84.50% 

88.40% 

88.10% 

81.60% 

88.30% 

79.00% 

83.40% 

83.40% 

76.10% 

86.60% 

78.30% 

Baseline 

96.80% 

97.00% 

81.50% 

0.71 

96.00% 

81.00% 

0.91 

91.80% 

92.60% 

78.10% 

92.10% 

77.50% 

86.80% 

87.20% 

74.30% 

85.00% 

70.70% 

81.80% 

81.70% 

70.60% 

82.90% 

69.30% 
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The  results  of  Table  22  were  plotted  to  provide  a  visual  representation  of  the  data  and  are 
provided  in  Figure  43  and  Figure  44.  When  evaluating  the  data,  the  lower  the  slope,  the  less 
sensitive  an  alternative  is  to  the  LRS  component  reliability  changes.  Utilizing  this  data,  it  was 
observed  that  Altemative-4  exhibited  the  greatest  sensitivity,  0.95,  to  LRS  component  changes 
effecting  reliability  during  launch,  but  exhibited  the  least  sensitivity  during  recovery,  0.79. 


The  sensitivity  slopes  identified  in  Table  22  defined  the  predicted  effects  of  varying  LRS 
reliability  in  relation  to  successful  launch  and  recovery  functions,  where  success  was  defined  as  a 
launch  or  recovery  that  is  not  detected  and  does  not  cause  any  damage  to  the  UUV  or  Host 
Platform.  This  information  was  used  when  alternative  LRS  components  were  evaluated  for  re¬ 
design  of  particular  concept  alternatives  and  how  it  will  affect  functional  performance.  The 
graphical  plots  Figure  43  and  Figure  44  identified  minimal  LRS  component  reliability  necessary 
to  satisfy  operation  threshold  and  objective  requirements. 

In  conclusion,  assuming  that  the  LRS  component  reliability  was  100%,  it  could 
extrapolated  from  the  sensitivity  slopes  the  best  likelihood  of  launch  and  recovery  success  is  for 
each  alternative.  Table  23  provides  the  probability  of  success  assuming  100%  LRS  reliability.  If 
the  probability  of  success  identified  in  Table  23  is  not  acceptable,  then  changes  to  design  and 
other  system  components  must  be  made  to  improve  the  likelihood  of  success. 

Table  23  -  Extrapolated  100%  LRS  Reliability 


Launch 

Recovery 

Alt  1 

92.03% 

90.18% 

Alt  2 

87.99% 

88.60% 

Alt  3 

89.14% 

89.57% 

Alt  4 

92.37% 

88.63% 

Baseline 

83.49% 

84.63% 

114 


Figure  43  -  Launch  Sensitivity 


Figure  44  -  Recovery  Sensitivity 
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IV.  DETAIL  DESIGN  CONSIDERATIONS 


A.  DESIGN  ASSESSMENT 

1.  Background 

Design  assessment  took  a  qualitative  approach  to  evaluate  each  conceptual  alternative 
design  considerations  in  support  of  a  final  recommendation.  Equipment  and  hardware/software 
interfaces  were  evaluated  to  ensure  that  cohesion,  coupling  and  connectivity  are  at  a  level 
necessary  to  exhibit  emergence  of  system  functions.  System  reliability  was  analyzed  to 
detennine  if  redundancy  was  at  the  correct  levels  to  provide  maximum  system  availability  at 
minimum  cost.  Safety  and  usability  were  assessed  to  examine  concept  alternatives  with  respect 
to  risks  imposed  on  the  host  submarines  and  users  as  well  as  potential  mitigations  which  could 
improve  overall  safe  operation.  Logistics  and  test  strategies  were  envisioned  to  help  validate  the 
acquisition  and  long  tenn  soundness  of  the  concept  alternatives.  Finally,  decision  analysis 
applied  a  process  to  the  results  of  the  modeling  and  analysis  to  recommend  an  approach  to  a  final 
concept  alternative. 

2.  Interface  Analysis 

Interface  analysis  compared  the  inputs  and  outputs  of  the  LRS  with  corresponding 
connections  to  internal  and  external  perfonners  for  the  overall  system.  The  analysis  assesses 
risks  for  the  physical,  power,  communications  and  system  level  interfaces.  Each  input  or  output 
to  the  LRS  was  traced  to  the  part  of  the  overall  system  that  provides  that  input  or  output.  Table 
24  provides  a  summary  of  the  interfaces  of  the  LRS,  and  between  the  LRS,  UUV  and  host 
submarine. 
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Interface 

Physical 

Power 

Comm  unications 

Dimensional 

LRS  Launcher  Mechanism  to 
UUV 

X 

X 

X 

LRS  Launcher  Mechanism  to 
LRS  Control  Station 

X 

X 

X 

LRS  Control  Station  to  Host 
Submarine 

X 

X 

X 

X 

LRS  Control  Station  to 
Submarine  Crew 

X 

LRS  Launcher  Mechanism  to 
Pavload  Tube 

X 

X 

LRS  Control  Station  to  LRS 
Operator 

X 

LRS  Recovery  Mechanism  to 
UUV 

X 

X 

X 

Table  24  -  System  Internal  and  External  Interfaces 
a.  Interface  Risks 

Risks  associated  with  the  four  (4)  categories  of  interfaces  are  detailed  below: 
Dimensional: 


•  A  securing/release  mechanism  sized  for  a  persistent-ISR  UUV  should  have  an  ability 
to  accommodate  a  smaller  UUV.  Since  the  size  of  a  smaller  UUV  was  not  defined, 
there  is  a  risk  with  accommodating  such  a  vehicle.  Incorporation  of  universal 
mechanisms  that  would  accommodate  various  sized  UUV’s  is  required. 

•  The  host  ship  control  room  or  torpedo  room  must  accommodate  the  physical 
dimensions  of  the  LRS  control  station.  Because  of  limited  space  availability,  there 
would  be  a  risk  of  a  non-ergonomic  installation  because  of  limited  locations  available 
for  installation.  A  study  of  availability  will  be  required  to  detennine  optimal  location 
for  installing  the  LRS  Control  Station.  It  might  be  necessary  to  integrate  LRS  control 
into  existing  workstations. 
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•  The  LRS  Control  Station  must  be  located  within  a  specified  visual  range  of  the 
Officer  of  the  Deck  (OOD)  to  support  real-time  continuity  with  host  submarine 
operations.  There  was  a  risk  to  the  launch/recovery  if  control  station  operators  did 
not  have  visual  observance  in  the  control  room  environment. 

•  The  launch  and  retrieval  mechanisms  must  fit  within  the  length  and  diameter  of  the 
payload  tube  without  interference  to  the  payload  tube  hatch.  A  risk  of  improper 
tolerances  could  lead  to  vibration  or  misalignment  of  the  launch/retrieval  mechanism. 
The  launch/retrieval  mechanism  must  be  designed  to  accommodate  vibration  and 
other  shipboard  motions  by  incorporation  of  standard  motion  dampening  mounts. 

Power: 

•  Wetted  power  distribution  plugs  must  provide  a  watertight  connection  with  UUV 
power  receptacle  and  provide  required  electrical  supply.  The  risk  of  a  non-watertight 
seal  results  in  poor  reliability  and  slow  power  transfer  rate  which  could  jeopardize  a 
mission  and  fail  to  meet  the  threshold  replenishment  time.  Design  of  watertight 
connections  should  leverage  off  proven  designs  currently  used  in  submarine  sonar  or 
vertical  launch  systems. 

•  A  power  cable  will  supply  electrical  and  battery  power  to  the  UUV  for  activation  of 
actuators.  Because  of  the  risk  of  host  ship  lacking  enough  reserve  power  to 
accommodate  launcher  power  requirements,  a  load  analysis  should  be  perfonned  to 
ensure  host  ship’s  ability  to  power  the  LRS. 

Communications: 

•  The  data  cable  connection  from  the  LRS  to  UUV  must  provide  a  watertight  mate  and 
provide  the  required  data  transfer  rate.  The  risk  of  a  non-watertight  seal  resulted  in 
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poor  reliability  and  slow  data  transfer  rate  which  could  jeopardize  a  mission  and  fail 
to  meet  the  threshold  launch  time.  Design  of  watertight  connections  should  leverage 
off  proven  designs  currently  used  in  submarine  sonar  and  vertical  launch  systems. 

•  The  noise  level  in  the  control  room  should  not  exceed  a  specified  level  due  to 
operating  equipment.  There  is  a  risk  of  misunderstanding  commands  between  the 
control  station  operator  and  OOD  if  noise  levels  from  the  control  station  exceed 
specified  levels.  Design  of  the  control  workstation  must  be  similar  to  other 
workstations  with  regard  to  noise. 

•  The  acoustic  and  Radio  Frequency  (RF)  communications  features  of  the  LRS  must 
have  signal  strength  to  clearly  transmit  infonnation  from  the  LRS  to  the  UUV  to 
support  the  UUV  recovery  process.  Signal  transmitters  should  utilize  commercially 
successful  systems  proven  to  propagate  in  various  water  conditions,  line-of-sight 
situations  and  background  noise  levels  without  jeopardizing  submarine  stealth. 

Physical: 

•  Shock  qualified  restraining  devices  must  hold  down  workstation  and  associated 
cables  piping,  etc.  There  would  be  a  risk  of  unrestrained  objects/equipment  during  a 
shock  event  which  could  injure  or  jeopardize  the  crew  or  ship.  The  required  grade 
shock  analysis  and  testing  must  be  performed  during  design  of  LRS  components. 

•  The  interface  between  operator  and  control  station  should  provide  an  ergonomic  input 
device.  A  risk  of  repetitive  stress  injury  could  occur  without  an  ergonomic  design. 
Use  of  latest  ergonomic  design  standards  is  required  for  us  in  design  of  input  devices. 
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b.  Software  Strategy 
Overview  of  Required  Work 

Requirements  and  Constraints  on  the  System  and  Software  to  be  developed: 

•  The  LRS  would  be  fully  integrated  into  an  existing  submarine  hull  and  control  room. 
The  software  must  accommodate  an  interface  between  the  LRS  control  station  and 
ship’s  communication  system,  as  well  as  the  LRS  control  station  and  the 
launch/recover  mechanism.  The  software  must  function  as  a  communications  link 
and  data  transfer  station  between  the  ship,  LRS  control  station,  LRS  launch/recover 
mechanism  and  the  UUV.  The  software  will  be  required  to  interface  with  and 
manipulate  the  launch/recovery  mechanism.  The  user  at  the  LRS  control  station  will 
be  using  a  dell  laptop  and  operate  the  system  through  a  GUI. 

Requirements  and  constraints  on  project  documentation: 

•  The  software  GUI  would  be  used  by  enlisted  sailors  under  possibly  stressful 
conditions.  Documentation  should  be  simply  stated  and  well  organized. 

Position  of  the  project  in  the  system  life  cycle: 

•  The  software  would  be  developed  to  support  software  specific  Developmental  Testing 
and  software/hardware  integration  into  the  LRS  for  its  Developmental  Testing,  and  be 
supported  and  maintained  throughout  all  Operational  Testing  and  service  life  of  the 
LRS. 

•  Constraints  from  Program/Acquisition  Strategy  -  There  were  no  constraints  from  the 
acquisition  strategy.  The  software  development  process  confonned  to  the  acquisition 
schedule  to  support  DT  and  OT. 
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Requirements  and  constraints  on  project  schedules  and  resources: 

•  The  software  development  process  would  begin  early  enough  to  not  invoke  risk  to 
software  reliability  in  order  to  meet  the  program  testing  schedule. 

Other  Requirements  and  Constraints: 

•  The  software  and  all  associated  documentation  shall  be  Distribution  Statement  D. 

Plan  for  Performing  Software  Development  Activities. 

Software  Development  Process: 

•  The  software  code  and  supporting  documentation  should  be  developed  for  the 
specific  architecture  of  each  viable  system  concept  to  support  a  fully  operational 
prototype  of  each  concept. 

General  Plans  for  Software  Development: 

Software  development  methods  -  Due  to  the  early  stage  of  development,  there  exists  a 
potential  for  mixing  and  matching  physical  concepts  as  the  design  matures.  As  such,  the 
supporting  software  will  need  to  be  interchangeable.  Definition  of  the  interfaces  between  each 
concept  shall  be  identified  at  a  global  software  level,  and  upheld  as  the  development  of  the 
software  code  continues.  Consistent  fonnat,  headers,  variable  identification  and  declaration  will 
be  used  throughout  the  software  development  phase.  A  consistent  methodology  will  also  be  used 
in  development  of  the  algorithms  for  each  module.  Each  module  will  be  tied  to  a  specific 
function  from  the  project's  functional  analysis.  This  development  scheme  allows  for  the 
maximum  flexibility  when  the  final  configuration  of  the  physical  concept  was  defined. 

Standards  for  software  products  -  Consistent  format,  headers,  variable  identification  and 
declaration  will  be  used  throughout  the  software  development  phase.  A  consistent  methodology 
will  also  be  used  in  development  of  the  algorithms  for  each  module. 
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Reusable  software  products  -  Due  to  the  simplistic  nature  of  the  functions  the  software  is 
required  to  fulfill  and  the  desire  for  maximum  commonality  between  modules  for  each  concept, 
reuse  of  existing  software  will  not  be  enacted.  Reformatting  existing  software  to  make  it 
compatible  with  each  of  the  concepts  will  not  be  an  efficient  use  of  time. 

Handling  of  critical  requirements  -  The  design  and  functions  do  not  contain  any  Fly-by- 
Wire  aspects.  As  only  one  penetration  for  power  and  data  is  required,  there  are  no  safety  critical 
aspects  that  relate  to  software.  No  software  modules  would  operate  components  in  the 
SUBSAFE  boundary. 

Computer  hardware  resource  utilization  -  The  development  would  take  place  using 
standard  desktop  computer  hardware.  No  special  hardware  requirements  are  needed  for  the 
development  of  these  modules. 

Recording  rationale  -  As  each  module  is  tested,  a  full  data  log  will  be  kept,  recording 
inputs,  outputs,  total  run  time  and  error  records. 

Access  for  acquirer  review  -  The  code  would  be  the  property  of  the  Department  of 
Defense  and  be  available  for  review  at  any  time. 

Plans  for  performing  detailed  software  development  activities 

Project  Planning  and  Oversight  -  The  lead  software  engineer  would  prepare  an  outline  of 
the  modules  to  be  developed  and  link  the  development  timeframe  of  that  outline  to  the  project 
design  schedule.  The  software  development  must  sync  up  with  key  design  milestones.  The  lead 
software  engineer  would  provide  weekly  status  updates  to  the  program  manager  regarding  the 
adherence  to  the  project  design  schedule. 
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Establishing  a  software  development  environment  -  Software  developers  would  be  co¬ 
located  and  have  ready  access  to  the  pre-defined  functional  decomposition  and  component 
selection  matrix  as  well  diagrams  of  the  component  physical  architecture  and  identified 
interfaces. 

System  Requirements  Analysis  -  Stakeholders  identified  their  top  level  requirements  for 
the  project.  These  requirements  have  been  consolidated  and  fonned  the  basis  for  the  functional 
architecture. 

System  Design  -  The  physical  architecture  was  defined  and  populated  with  components 
from  the  component  selection  matrix.  Different  components  of  the  physical  architecture  were 
mapped  to  specific  functions.  The  architecture  would  not  change  for  the  duration  of  the  project 
without  redefining  the  scope  of  the  project. 

Software  Requirements  Analysis  -  From  the  functional  decomposition  and  component 
matrix,  the  project  will  identify  any  function  that  requires  the  aid  of  software.  Each  concept 
required  its  own  software  modules  based  on  specific  components  of  that  concept.  Each  module 
would  be  written  with  the  understanding  that  concepts  could  swap  components  as  the  design 
matures.  The  software  must  be  able  to  handle  that  adaption. 

Software  Design  -  Each  module  would  be  developed  for  a  specific  function  and 
supporting  component.  Inputs  and  outputs  would  be  detennined  by  the  interfaces  between  the 
components. 

Software  Implementation  and  Unit  Testing  -  As  the  software  development  must  match 
the  project  development  milestones,  implementation  and  testing  would  be  scheduled  with  ample 
time  to  address  implementation  issues.  Because  each  module  was  developed  for  this  project  (no 
re-use  of  existing  software),  debugging  can  be  accomplished  with  project  specific  inputs  and 
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environments.  This  would  eliminate  integration  issues  that  would  arise  from  software  re-use. 
Each  module  would  be  tested  with  simulated  inputs  before  software/software  integration.  Once 
each  module  passed  individual  testing,  modules  that  need  to  be  combined  before 
hardware/software  integration  would  be  tested  with  simulated  inputs. 

Unit  Integration  and  Testing  -  Once  a  series  of  modules  were  combined  and  successfully 
tested,  hardware/software  integration  would  be  accomplished  prior  to  component  integration. 
This  would  allow  for  simulated  inputs,  based  on  the  recognized  interfaces,  to  be  used  in 
individual  component  testing.  Any  bugs  would  be  fixed  prior  to  component  integration.  The 
simulated  inputs  would  mimic  actual  inputs  as  close  as  possible. 

System  Qualification  Testing  -  The  software  would  be  tested  in  each  component  prior  to 
component  to  component  integration.  The  software  qualification  testing  would  be  considered 
complete  if  the  integrated  prototype  met  requirements  satisfied  by  software  implementation. 

Preparing  for  Software  Use  -  Each  member  of  the  design  development  team  or  operating 
crew  would  be  trained  on  the  proper  use  of  the  software.  Manuals  with  instructions  and 
troubleshooting  guides  are  to  be  provided  to  each  trainee  as  well  as  made  available  with  each 
workstation,  which  operates  the  software. 

Software  Configuration  Management  -  An  outline  of  variable  usage,  headers,  comments, 
and  language  is  provided  to  each  software  developer.  In  addition,  at  weekly  meetings,  examples 
of  current  code  were  displayed  for  all  developers  to  verify  that  their  efforts  mimic  the  displayed 
code  fonnat.  Each  developer  shall  be  individually  responsible  for  his  own  version  control  of  the 
software.  Once  he  has  completed  a  module,  it  would  be  turned  over  to  the  lead  software 
engineer  for  archive  purposes  and  is  stored  until  individual  or  integrated  testing  is  to  take  place. 
Once  software  has  been  successfully  integrated  into  a  component,  it  will  have  a  unique  version 
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number  identifying  it  as  a  working  software  package.  A  standard  revision  system  would  be 
levied  on  the  software  development  efforts.  Each  updated  version  to  a  software/hardware 
integrated  component  would  follow  the  revision  format.  The  lead  software  engineer  would  be 
responsible  for  integration  of  the  software  package  into  the  hardware  component. 

3.  Reliability  Analysis 

The  LRS  has  a  robust  reliability  strategy  that  meets  current  DOD  requirements.  [OSD 
ETDM,  2011]  Reliability  is  a  system  engineering  discipline  and  the  requisite  actions  and 
activities  are  embedded  in  the  tasks  listed  in  the  integrated  master  schedule.  For  example, 
reliability  strategies  were  integrated  as  part  of  the  overarching  design  review  and  test  and 
evaluation  process.  Reliability  program  success  will  be  judged  by  meeting  objectives  for  Mean 
Time  between  Failures  (MBTF)  and  Mean  Time  between  Operational  Mission  Failures 
(MTBOMF),  which  supports  system  Operational  Availability. 

Design  for  reliability  methodologies  were  planned  throughout  the  design  selection  and 
development  process.  These  include: 

•  Block  Diagrams  and  Predictions 

•  Failure  Modes,  Effects  and  Criticality  Analysis  (FMECA) 

Block  Diagrams  and  Predictions  were  planned  to  detennine  preferred  system 
redundancies  (e.g.  dual  power  supplies,  dual  software  routines,  back-up  control  systems),  and 
sparing  requirements.  During  the  concept  exploration  phase,  initial  reliability  comparisons  were 
made  between  the  baseline  model  and  the  four  identified  alternatives.  The  output  data  from  the 
ExtendSIM®  model  provided  the  early  look  reliability  numbers  of  each  top  level  function  based 
on  the  percent  success  report  from  ExtendSIM®.  Among  the  different  concepts,  the  reliability 
of  each  top  level  function  was  compared  as  well  as  the  overall  concept  reliability.  At  this  stage 
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of  development,  predicting  or  assigning  reliability  targets/values  to  any  sub  level  functions 
cannot  be  done  with  any  degree  of  fidelity.  The  fonnula  for  top  level  reliability  analysis  based 
on  functional  reliability  is: 


"^T  otal  ^  "^Launch  )*(*  Recovery  )*(*  Reolenish  )*(R 

Maintain  ) 


Replenish  /  V  Maintain  > 


This  concept  is  illustrated  in  Figure  45. 
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Figure  45  -  Top-Level  Reliability  Diagram 

The  second  reliability  block  diagram  option,  Figure  46,  took  advantage  of  the  redundancy 
with  electronic  and  software  components,  which  comprise  the  majority  of  the  “Replenish”  and 
“Maintain”  function  components.  Without  a  large  volume  or  weight  penalty,  physical 
components  of  replenish  and  maintain  were  arranged  to  offer  additional  redundancy  to  the 
functions.  The  reliability  advantage  of  this  redundancy  was  represented  in  the  reliability 
calculations  such  that  a  0.90  reliability  allocation  to  each  replenish  or  maintain  subsystem 
increase  the  combined  reliability  of  replenish  or  maintain  functions  to  0.99,  using  the  formula: 

R  =  Ra+Rb-(R^Rb) 

This  resulted  in  a  combined  replenish  and  maintain  reliability  of  0.99  *  0.99,  or  0.98. 
While  arranged  in  series,  two  functions  with  0.90  reliability  provide  a  combined  reliability  of 

R  *R  =0.9*0.9  =  0.81 

A  B 

Due  to  large  reliability  benefit  of  redundancy  in  these  two  systems,  early  integration  of 
redundancy  should  be  considered.  The  overall  reliability  of  this  system  model  is  calculated  with 
the  equation: 
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Figure  46  -Reliability  Diagram  with  Redundancy 


The  third  and  most  complex  reliability  block  diagram  arrangement,  Figure  47,  took 
advantage  of  a  highly  integrated  system.  For  this  arrangement,  launch  and  recover  were  again  in 
series,  but  replenish  and  maintain  have  redundancy  amongst  themselves  (as  in  the  second 
reliability  block  diagram  concept)  while  performing  simultaneous  functions.  For  example,  a 
diagnostic  process  could  be  run  at  the  same  time  as  replenishment.  The  reliability  advantage  of 
this  redundancy  was  such  that  a  0.90  reliability  allocation  to  replenish  or  maintain  subsystems 
will  again  prove  to  be  0.99,  but  when  these  two  functions  are  arranged  in  parallel,  their  combined 
reliability  (replenish  =  0.99  and  maintain  =  0.99)  is  0.9999.  The  reliability  was  then  expressed 
as: 
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Figure  47  -  Integrated  System  Reliability  Block  Diagram 


Output 


A  Failure  Modes  and  Effects  and  Criticality  Analysis  (FMECA)  were  used  to  analyze  the 
risks  or  weaknesses  of  different  types  of  system  components  which  could  adversely  affect  the 
overall  system  reliability.  This  analysis  used  the  requirements  analysis,  functional  analysis,  and 
requirements  allocation  as  a  starting  point.  The  failure  modes  are  identified,  which  includes  the 
methodology  by  which  the  system  fails  to  function  (or  a  component  fails  to  support  the  system 
functioning).  The  root  causes  were  identified;  (Does  the  hatch  fail  due  to  a  sealing  surface,  or 
due  a  faulty  fastener?)  The  effects  of  the  failure  were  then  determined,  along  with  the  detection 
methods,  frequency  and  criticality.  This  data  is  used  to  recommend  changes  to  the  design,  as  well 
as  the  supportability  requirements.  The  analysis  would  be  planned  for  the  design  phase  to 
minimize  re-work.  Table  25  identified  potential  failures,  critical  analysis  and  mitigations  for 
LRS  component  packages. 
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Table  25  -  Example  Failure  Modes  Effects  and  Criticality  Analysis 


Functional  Failure 

Systems  Failures 

Consequence 

Mitigations  /  Design 
Recommendations 

Launch  System  fails  to 
launch  UUV  when 
command  is  given 

Launch  System  software 
fails  to  initiate  system. 

UUV  remains  in  submarine 
in  dormant  state. 

UUV  is  not  available  for 
mission. 

Mechanical  Backup  launching 
system  or  Manual  Over-ride. 

Redundant  Software  Systems 

Stowage  and  Support 
Structure  fails  to  securely 
stow  the  UUV 

Support  Structure  Failure 

UUV  damage  to  ship 

Potential  injury  to  crew 

Structural  analysis  of  failure 
points,  additional  support  to 

UUV 

Damage  to  UUV  could 
preclude  it  being  launched 

Use  robust  structural  components 

Stowage  Mechanism 

Failures 

Loose  UUV  falls  and 
damages  submarine  injures 
crew  or  damages  UUV 

Backup  mechanisms  for  secure 
stowage 

Consider  independent 
mechanical/electrical  systems 

Failure  to  collect  UUV 
payload  data 

Communications  systems 
failure 

UUV  data  collected  is  lost 
and  not  available  for 
subsequent  missions. 

Potential  enemy  recovery  of 
classified  data  and 
technology. 

Redundant  communications 
methods. 

Mechanical  recovery 
mechanisms  fail  to  interface 
with  UUV 

Loss  of  UUV  and  collected 
data. 

UUV  damages  ship. 

No  ability  to  re-launch  UUV 
for  subsequent  missions. 
Damage  to  intelligence  if 
recovered  by  enemy 

Design  interface  with  backups 

Use  remote  or  proximity  vice 
direct  interfaces 

UUV  control  system  fails 

Control  of  UUV  is  lost  as  it 
approaches  submarine 

UUV  damages  submarine 
pressure  and  or  non-pressure 
hull  structure. 

Control  System  architecture  must 
have  robust  design  with  safety 
analysis  done. 

UUV  itself  is  damaged, 
causing  the  data  collected 
not  to  be  recoverable.  This 
results  in  the  loss  of 
intelligence  as  well  as  the 
potential  loss  of  the  ability 
to  re-launch  UUV  for 
subsequent  missions. 

Redundant  System  to  address 
failure  of  operating  laptop  with 
ability  to  port  software  onto  a 
“standard  laptop”  if  available. 

4.  Safety  and  Usability  Analysis 

A  Failure  Modes  and  Effects  and  Criticality  Analysis  (FMECA)  addressed  the  Safety 
Risks  to  the  submarine  and  personnel  associated  with  the  launch  and  recovery  of  Large  Vehicle 
Class  UUVs.  Among  the  risks  addressed: 
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•  Implodable  Volumes  -  Defined  as  “any  pressure  housing  containing  a  non- 
compensated  compressible  volume  at  a  pressure  below  the  external  sea  pressure  (at 
any  depth  down  to  the  maximum  operating  depth)  which  had  the  potential  to 
collapse.”  Externally  mounted  lights,  gauges,  bottles/flasks,  spheres/tanks  and 
beacons  are  examples  of  implodable  items.  The  LRS  shall  minimize  implodable 
volumes.  Structural  materials  with  sealed  internal  cavities  (Carbon  Steel,  Titanium) 
could  pose  issues  as  well  as  Gas  Generator  Launch  components  with  gas  storage 
flasks. 

•  Collision  -  The  consequences  of  a  large  UUV  crashing  into  the  submarine  structure 
are  severe,  with  the  potential  for  damage  to  the  submarine  hull,  causing  an 
uncontrollable  flooding  casualty.  The  risk  to  the  submarine  is  minimized  during  the 
time  that  the  UUV  is  deployed  and  being  recovered  by  the  control  system.  Systems 
that  control  the  UUV  approach  to  the  submarine  such  as  an  EMP  Attraction  Device  or 
ROVs  would  be  favored  over  systems  where  the  UUV  must  navigate  to  a  docking 
location. 

•  Off-Gassing  Hazards  -  The  UUV  power  systems  have  the  potential  to  release 
explosive  gases  (e.g.  hydrogen  and  oxygen).  Sealed  and  dry  stowage  systems  may  be 
more  susceptible  to  the  build-up  of  gases  and  must  consider  ventilation  to  support 
safe  operation. 

•  System  Installation  and  Removal  -  The  stowage  system  will  be  designed  to  maximize 
the  use  of  cranes  and  jigs  for  loading  the  UUV  into  its  final  launch  position  prior  to 
the  submarine’s  deployment.  The  LRS  would  use  of  harnesses  and  jigs,  to  minimize 
the  risk  of  physical  injury  to  ships  force  when  reloading  the  UUV  into  the  submarine. 
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Lightweight  composite  structures  that  minimize  equipment  requirements  and  training 
would  be  preferred  over  heavier  and  rigid  equipment. 

•  Underwater  Explosion  Risk  -  All  internal  and  external  components  would  be 

designed  to  meet  MIL-STD-801  Grade  B  shock  requirements  to  minimize  the  risk  of 
injury  in  an  underwater  explosion  event.  Grade  B  shock  means  that  the  equipment 
will  maintain  structural  integrity  but  not  function.  Communications  and  control 
system  equipment  must  be  designed  for  installation  into  the  existing  equipment  racks. 
Outboard  equipment  must  not  come  adrift  and  impact  function  and  operation  of  other 
submarine  components.  Rigid  metallic  components  and  electrical  components  with 
limited  mechanical  parts  would  be  desired  to  best  resist  shock  events. 

5.  Test  and  Evaluation  Strategy 

The  Test  and  Evaluation  Strategy  (TES)  for  the  LRS  provides  an  overview  into  the 
necessary  testing  at  various  stages  of  concept  development.  Specific  strategy  recommendations 
are  provided  as  Appendix  E. 

The  test  strategy  for  all  potential  conceptual  alternatives  relies  on  Modeling  and 
Simulation  (M&S)  during  early  development,  component  specific  Demonstration  Test  and 
Evaluation  (DT&E)  performed  by  contractors  with  Government  oversight  and  Operational  Test 
and  Evaluation  (OT&E)  performed  on  a  fully  integrated  prototype  model.  In  general,  M&S  and 
DT&E  processes  are  considered  relatively  low  risk.  Many  proposed  component  alternatives  are 
technically  mature  and  those  which  require  laboratory  development  are  based  on  demonstrated 
scientific  principles.  Demonstration  testing  of  integrated  mechanical  system  components,  such 
as  the  launch,  recovery,  stowage  and  structural  systems,  using  Large  Vehicle  Class  UUV 
representative  models  is  possible  in  Government  laboratory  facilities  with  minimal  resource 
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requirements.  Demonstration  testing  of  control  and  communication  components  can  effectively 
be  combined  with  operational  testing  as  all  component  concepts  are  Commercial-Off-The-Shelf 
and/or  currently  in-service  technologies. 

Operational  testing  represents  the  highest  level  of  program  and  perfonnance  risk  for  all 
anticipated  concepts.  As  such,  the  test  strategy  recommends  two  (2)  phases  of  OT&E  to  limit  the 
testing  time  with  in-service  submarine  resources.  Phase  I  would  test  a  fully  integrated  LRS 
prototype  in  a  Virginia  Payload  Tube  (VPT)  model,  using  representative  Large  Vehicle  Class 
UUV  models.  Testing  would  be  accomplished  at  US  Navy  test  tank  facilities  at  Bethesda,  MD 
and  would  focus  on  successful  operation  of  a  fully  integrated  system  in  a  controlled 
environment.  Upon  satisfactory  Phase  I  testing,  environmentally  realistic  testing  (Phase  II) 
would  be  conducted  using  a  target  Large  Vehicle  Class  UUV  and  a  VA  Class  Block  III 
submarine.  Phase  II  testing  would  concentrate  on  vehicle  deployment  and  recovery  from  a 
submerged  and  moving  submarine  and  would  assess  the  radiated  noise  from  an  operating  system. 
Additionally,  Phase  II  will  address  human  factors  and  training  of  system  users  as  well  as 
integration  and  data  flow  problems  between  the  UUV  and  the  submarine  via  the  LRS. 

Significant  issues  identified  during  Phase  II  testing  would  be  analyzed  for  corrections  not  only 
during  successive  increments  of  the  LRS,  but  also  during  successive  builds  of  the  VA  Class 
submarines  and  commercial  UUVs. 

6.  Logistics  Strategy 

As  part  of  the  preliminary  and  detailed  design  effort  a  logistics  support,  trade-off  and 
maintainability  analysis  will  be  addressed.  A  level  of  repair  analysis  (LORA)  will  be  done  to 
identify  what  components  may  be  repaired  or  replace  at  the  operational  (O-level),  intennediate 
(I-  Level),  or  depot  maintenance  level.  Consistent  with  the  current  U.S  Navy  policy,  a  reliability 
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centered  maintenance  (RCM)  concept  will  be  applied  to  minimize  total  ownership  costs.  In 
addition,  the  use  of  unique  components  would  be  minimized,  specifically  components  required  to 
be  carried  as  on  board  repair  parts  (OBRP).  The  use  of  common  components  minimizes  or 
eliminates  the  need  for  extra  maintenance  training.  Components  would  be  analyzed  to  determine 
which  could  be  “swapped  out”  and  repaired  off  hull  vice  shipboard.  The  issues  and  risks  to  be 
addressed  in  design  development  would  include: 

•  Durability  of  the  carbon  fiber  vice  titanium  or  carbon  steel  structure. 

•  LRS  structural  material  compatibility  with  existing  host  submarine  operating 
environments  and  platform  requirements. 

•  Preservation  costs  of  high  strength  carbon  steels. 

•  Identification  of  special  training  and  certification  requirements  for  technicians 
maintaining  the  LRS  associated  with,  but  not  limited  to;  installation,  preventative  and 
scheduled  maintenance,  equipment,  and  facilities  necessary  to  accommodate 
maintenance. 

•  The  use  of  commonality,  open  system  architecture  and  interfaces  to  optimize 
logistical  support  of  LRS  for  preparation  of  future  system  obsolescence. 

•  Identification  of  LRS  components  located  internal  to  the  payload  tube  and  external  to 
the  host  pressure  vessel,  which  are  inaccessible  during  deployment  so  that  design  can 
stress  reliability  needs  for  maximized  availability  and  component  maintainability 
when  in  port. 

•  Limiting  the  use  of  unique  components  and  procedures  that  affect  the  ability  to 
complete  availabilities  on  schedule  within  cost  due  to  parts  availability  and  the  use  of 
specialty  processes. 
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The  final  maintenance  requirements  and  logistics  support  shall  be  consistent  and 
compatible  with  existing  VA  class  submarine  practices.  This  should  include  the  use  of  Re-entry 
Control  (REC)  processes  for  work  in  the  SUB  SAFE  boundary.  All  maintenance  should  be 
scheduled  in  the  ships  Consolidated  Ships  Maintenance  Plan  (CSMP)  for  accomplishment. 
Standard  Test  Procedures  should  be  developed  to  test  the  LRS  after  maintenance  and  during  sea 
trials. 

B.  DECISION  EVALUATION 

1.  Background 

Decision  making  under  risk  and  uncertainty  is  the  final  step  in  all  System  Engineering 
processes.  The  goal  of  decision  making  was  to  gather  infonnation  about  many  different  choices, 
convert  these  choices  to  comparative  quantitative  and  qualitative  measures,  establish  a  model 
that  represented  the  comparisons  in  a  fair  and  unbiased  fashion  and  demonstrated  to  the 
stakeholders  that  the  model  identifies  the  best  choice  when  compared  to  the  stakeholder’s  value 
system.  [Blanchard  &  Fabrycky,  2006,  pg.  164]  Decision-making  highlighted  the  importance  of 
eliciting  stakeholder  requirements,  requirements  traceability  and  re-iterative  validation  of 
stakeholder  concerns  during  each  process  and  phase  of  the  Systems  Engineering  model.  Simply 
put,  even  the  best-engineered  systems  provide  no  value  to  a  stakeholder  if  they  do  not  meet  their 
intended  needs. 

As  would  be  expected  for  most  engineered  systems,  the  modeling  and  evaluations 
conducted  with  respect  to  the  LRS  did  not  identify  one  preferred  concept  alternative. 
Additionally,  based  on  stakeholder  input,  life-cycle  costs  of  the  system  was  only  one  factor  in  the 
process.  Therefore,  to  detennine  which  alternative  provided  the  best  solution  to  the  war  fighter’s 
needs,  the  team  compared  the  values  of  each  concept  alternative. 
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The  value  assigned  to  a  system  can  be  considered  the  “Use”  that  is  expected  for  the 
“Investment”  into  the  system.  The  “Use”  of  the  system  can  be  expressed  as  the  operational 
capability  of  a  system’s  functions,  perfonnance  and  quality  and  can  be  expressed  as  a  function, 
or  “Use”  =  /(functions,  perfonnance,  quality).  Not  all  functional  capabilities  of  a  system  provide 
equal  use  to  a  set  of  stakeholders  or  even  to  one  specific  stakeholder  with  respect  to  other 
stakeholders.  As  such,  a  weighting  system  was  utilized  to  express  those  capabilities,  which 
provided  greater  use  vice  those  which  provided  less  use.  This  trade-offs  of  functional 
capabilities,  perfonnance  and  system  quality  provided  a  rationalized  approach  to  the  team’s  final 
recommendations. 

2.  Alternative  Scoring 

To  detennine  the  “Use”  of  each  concept  alternative,  the  team  examined  the  results  of  six 
(6)  areas  of  comparison  accomplished  during  the  Capstone  project:  Risk,  Perfonnance, 
Interfaces,  Reliability,  Safety/Usability  and  Logistics.  The  examination  of  concept  alternative 
perfonnance  was  accomplished  via  a  quantitative  approach  using  the  results  of  modeling  and 
simulation.  The  examination  of  the  other  five  factors  was  done  qualitatively  using  guidance 
established  for  each  the  specific  system  components.  The  following  rules/guidelines  were 
established  to  support  the  analysis: 

•  Each  concept  alternative  was  compared  to  the  other  alternatives  with  respect  to  the 
top  seven  (7)  weighted  design  characteristics  (stakeholder  requirements)  identified  in 
Figure  11.  The  bottom  three  (3)  weighted  design  characteristics  (System  Weight, 
Payload  Space  and  Data  Transfer  Parameters)  add  only  13%  (weighting  of  1.6 
compared  to  12.5  total  weighting)  to  the  overall  concept  value.  Additionally,  the 
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commonality  of  many  concept  alternative  components  with  respect  to  these 
characteristics  provides  little  separation  between  rankings  of  concepts. 

•  For  each  area  of  comparison,  at  least  one  (1)  alternative  was  considered  best  and  was 
assigned  a  rank  of  “5”  (adds  the  most  “Use”).  If  the  modeling  and  evaluations 
resulted  in  no  significant  differences  between  the  alternatives,  all  were  assigned  a 
rank  of  “5”. 

•  The  other  alternatives  not  considered  the  best  alternative  received  rankings  of 
between  “1”  and  “4”.  No  alternative  was  ranked  below  “1”.  In  addition,  multiple 
alternatives  could  be  ranked  the  same  if  modeling  and  evaluations  resulted  in  no 
significant  differences  between  them. 

•  Comparisons  of  the  alternatives  were  made  against  each  other  alone  and  not  based  on 
outside  factors  (i.e.,  reliability  with  respect  to  battery  charging  capacity  was  made 
with  respect  to  the  proposed  system  components  and  did  not  consider  an  alternate, 
theoretical  component  with  anticipated  higher  reliability). 

•  The  stakeholder  value  system  ranks  “Safety”  and  “Performance”  as  two  of  the  most 
desired  characteristics  for  the  LRS.  Therefore,  Safety/Usability  and  Performance 
rankings  were  weighted  twice  as  much  as  rankings  for  Risk,  Interfaces,  Reliability 
and  Logistics. 

A  table  was  created  for  each  of  the  seven  (7)  design  characteristics,  comparing  each  of 
the  concept  alternatives  in  each  of  the  six  (6)  areas  of  comparison,  resulting  in  42  data  points  for 
each  concept  alternative.  The  “Use”  for  design  characteristic  “Recovery  Speed”  is  a  summation 
of  the  rankings  in  the  six  (6)  areas  of  comparison  multiplied  by  the  design  characteristic  weight 
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identified  in  Figure  1 1  provides  the  comparison  matrix  of  the  design  characteristic  “Recovery 
Speed”.  Detailed  tables  for  all  the  comparisons  are  provided  in  Appendix  F. 

The  scoring  system  which  potentially  ranked  one  concept  5  times  more  useful  to  the 
stakeholders  than  another  concept  identified  the  possibility  of  unintended  bias.  To  examine  the 
effects  of  this  bias,  the  team  explored  different  scoring  systems,  which,  increased  or  shrank  the 
spread  between  the  rankings  of  the  alternatives.  Assuming  that  the  ranks  of  the  concepts  in  the 
six  areas  of  comparison  were  in  the  correct  order,  changing  the  spread  did  not  significantly 
change  the  results  of  the  analysis.  For  instance,  using  a  scoring  system  of  1,  10,  25,  50,  100 
(high  penalty  for  lower  ranked  alternatives)  provided  a  curve  similar  to  that  shown  on  Figure  48 
where  Alternative  4  still  dominates  Alternative  2  for  approximately  the  same  cost.  Likewise, 
when  the  reverse  methodology  was  used  and  a  scoring  system  of  1,  1.01,  1.025,  1.05,  1.1  (low 
penalty  for  lower  ranked  alternatives)  was  applied,  the  results  were  similar.  As  such,  the  team 
concluded  that  as  long  as  a  scoring  system  with  a  reasonable  spread  was  chosen,  the  final  shape 
of  the  curve  remained  unchanged  assuming  rankings  and  cost  values  did  not  change. 


Table  26  -  Stakeholder  Use  Matrix  (Recovery  Speed) 


Recovery 

Speed 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum  of 
Ranks) 

Baseline 

1 

1 

1 

1 

1 

5 

27.6 

ALT-1 

5 

4 

5 

5 

5 

1 

78.2 

ALT-2 

2 

2 

2 

2 

2 

4 

41.4 

ALT-3 

5 

3 

3 

4 

3 

3 

62.1 

ALT-4 

5 

5 

5 

3 

5 

1 

78.2 

By  summing  an  alternative’s  “Use”  numbers  for  all  design  characteristics,  an  overall 
“Use”  to  stakeholder  number  was  developed  for  the  alternative.  These  numbers  identified  in 
Table  27  and  plotted  against  the  Life-Cycle  Cost  for  each  alternative  in  Figure  48.  Based  on  the 
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plot,  the  Baseline,  Alternative  4  (High  Tech)  and  Alternative  1  (Attraction  Recovery)  dominate 
Alternatives  2  and  3.  Furthennore,  assuming  Life-Cycle  Cost  is  a  consideration  but  was  not  the 
only  consideration;  Alternative  4  delivered  the  best  Value,  defined  as  Use  /  Investment  to  the 
stakeholders  and  was  recommended  for  further  study.  It  is  noted,  as  previously  discussed,  “Use” 
was  a  term  established  to  support  comparative  overall  ranking  of  the  alternatives  and  does  not 
provide  a  factor  of  Value  for  one  alternative  over  another.  Hence,  Alternative  2  provided  nearly 
the  same  Value  as  the  best  choice  (Alternative  4)  and  would  also  merit  further  study  to  validate 
costs  and  trade-offs.  Alternatives  1  and  3  provided  little  additional  “Use”  for  cost  and  were 
eliminated  from  future  analysis.  The  Baseline  alternative  was  comparatively  inexpensive  but 
provided  little  “Use”  to  meet  stakeholder  needs  and  also  was  eliminated  from  future  analysis. 

Table  27  -  Stakeholder  Use/LCC  per  Alternative 


Total 

Use 

LCC  ($M) 

Baseline 

140 

21.37 

ALT-1 

297.3 

56.25 

ALT-2 

224.6 

41.76 

ALT-3 

245.8 

56.62 

ALT-4 

285.4 

37.36 
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Figure  48  -  Concept  Alternative  Value  to  Stakeholders 
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V.  SUMMARY,  CONCLUSIONS  AND  LESSONS  LEARNED 

This  Capstone  project  focused  on  the  considerations  and  interfaces  needed  to  successfully 
field  and  support  a  system  that  would  launch,  recover,  replenish,  stow  and  transfer  information 
between  current  and  future  Large  Vehicle  Class  UUVs  and  host  submarines,  specifically 
submarines  with  the  VA  Class  Block  III  payload  tube  concept.  This  system  will  provide  a 
capability  to  support  persistent-ISR  missions  identified  in  the  UUV  Master  Plan  of  2004  by 
providing  stealthy  infonnation  collection  capabilities,  threat  and  harbor  monitoring,  WMD 
identification  and  sea  floor  object  reconnaissance. 

To  accomplish  the  project  objectives,  the  Capstone  team  used  a  three-phase  Systems 
Engineering  approach  to  analyze  and  develop  system  requirements,  detennine  system  functions, 
cost  and  perfonnance  guidance  and  to  identify  system  design  needs  and  constraints.  The 
outcomes  and  results  generated  from  each  phase  were  validated  against  a  derived  value  system 
for  the  stakeholders  and  used  as  the  foundation  for  each  successive  system  engineering  phase. 
Observations  and  insights  of  each  phase  of  the  project  are  highlighted  below,  culminating  in  a 
recommended  approach  to  the  design  and  implementation  of  a  system  that  supports  the 
objectives. 

A.  PROJECT  SUMMARY 

System  Requirements  Analysis 

The  initial  step  in  the  system  engineering  process  was  to  develop  a  set  of  requirements 
for  the  LRS.  As  designs  currently  exist  that  integrate  UUVs  with  submarine  torpedo  tubes  and 
converted  SSGN  missile  tubes,  the  Capstone  team  used  these  concepts  as  starting  points  for 
stakeholder  identification  and  system  requirements.  During  this  process,  two  (2)  significant 
issues  were  identified;  UUV  requirements  creep  and  implied  problems  with  current  designs. 
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The  UUV  Master  Plan  of  2004  remains  as  the  only  documented  guidance  with  respect  to 
persistent-ISR  notional  capabilities  and  concepts  of  operation.  In  particular,  the  Master  Plan 
identifies  an  on-station  endurance  of  300+  hours  (approximately  2  weeks).  However,  during  the 
course  of  the  Capstone  project,  three  (3)  additional  documents  [Ashton,  2010;  Anderson  2011, 
Taylor,  2011]  were  issued  that  discuss  on-station  endurance  goals  of  between  46  and  120  days. 
Additionally,  Taylor,  2011  discusses  a  maximum  length  of  45  feet  for  a  LDUUV  (which  exceeds 
the  diameter  of  a  VA  Class  submarine)  and  highlights  the  need  for  payload  upgrades,  better 
autonomy  and  system  redundancies.  Although  all  three  documents  serve  to  challenge  the  UUV 
development  community  to  explore  alternate  power  and  control  technologies  and  do  not  “reset” 
guidance  provided  by  the  2004  Master  Plan,  they  do  highlight  the  challenges  that  faced  the  team 
with  respect  to  defining  the  Large  Vehicle  Class  UUV  external  boundary  for  the  LRS. 

Interviews  with  SMEs  identified  efforts  to  integrate  a  ULRM-like  system  with  VA  Class 
Block  III  submarines  and,  potentially,  Block  IV  and  Block  V  submarines.  However,  responses 
indicated  a  variety  of  concerns  and  challenges  with  this  approach.  For  instance,  hovering 
capabilities  of  SSGN  submarines  allow  a  UUV  to  swim  to  a  deployed  cradle  while  topside 
recovery  by  a  moving  submarine  will  require  both  vessels  to  match  speeds  and  maneuver  to 
avoid  the  submarine  sail.  Additionally,  current  power  resources  at  the  forward  end  of  the  VA 
Class  submarine  may  require  significant  modifications  to  support  replenishment  of  the  UUV 
power  supply.  Finally,  as  shown  in  Figure  49  and  discussed  in  McDermott,  2011,  even  the 
location  and  design  of  VA  Class  submarines  with  respect  to  the  location  and  function  of  the 
payload  tubes  remains  under  review.  Although  none  of  these  integration  issues  appear 
insurmountable,  they  do  represent  an  approach  to  UUV/VA  Class  submarine  integration  which 
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could  increase  the  cost,  schedule  and  performance  risks  to  the  LRS  if  designers  and 
implemented  focus  on  the  wrong  requirements  and  wrong  future  mission  scenarios. 


The  Future  of  SSGN  Strike 


Virginia  Payload  Module  Concept 


Figure  49  -  Proposed  Future  VA  Class  Submarine  Payload  Tube  Configuration 

[McDermott,  2011] 

A  primary  role  of  the  System  Engineer  is  to  develop  a  set  of  requirements  and  a  preferred 
approach  that  provides  the  best  value  to  multiple  stakeholders.  To  that  end,  the  Capstone  team 
took  a  long-term  approach  to  establishing  system  requirements,  recognizing  that  future  value 
which  stressed  flexibility,  safety  and  life-cycle  costs  would  best  serve  the  stakeholder  concerns. 
Host  submarine  safety,  accommodation  of  power  sources,  maximization  of  launch  and  recovery 
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performance  and  system  affordability  were  ranked  as  the  four  (4)  most  critical  needs  expected 
for  a  successful  system. 

With  the  requirements  for  the  LRS  established,  the  Capstone  team  focused  on  developing 
the  functional  architecture.  The  functional  architecture  helped  identify  the  resource  requirements 
for  the  system  in  terms  of  equipment  and  materials,  people,  support  facilities  and 
maintenance/logistics  considerations.  Using  CORE®,  by  Vitech  Corporation,  the  team 
accomplished  the  functional  decomposition  to  map  functions  to  physical  component  and 
performers  and  to  map  functions  to  system  requirements.  The  top-level  functions  of  “Launch”, 
“Recover”,  “Maintain”  and  “Replenish”  were  established  for  the  system.  One  internal  system 
performer  (Launch  and  Recovery  System  Operator)  was  identified  while  first-level  external 
performers  (Host  Submarine  Operator,  Autonomous  UUV)  and  second-level  external  performers 
(Navy  Support  Agency,  UUV  Equipment  Providers,  and  Maintenance/Logistics  Providers)  were 
assigned  the  functional  responsibilities.  With  the  operational  and  component  hierarchies 
established,  decomposition  continued  to  allocate  functions,  tasks  and  requirement  to  ensure  that 
no  necessary  actions  were  missed  and  no  unnecessary  actions  were  included.  Lunctional  flow 
block  diagrams  were  created  to  verify  how  information  was  exchanged  between  performers  and 
components  and  operational  views  (OV-2,  OV-5)  and  system  views  (SV-4)  were  generated  to 
pictorially  describe  the  infonnation  flows  between  the  aspects  of  the  system. 

Functional  Analysis 

Following  development  of  system  requirements  and  functional  architecture,  Quality 
Function  Deployment  (QFD)  models  were  used  to  translate  the  system  requirements  into  distinct 
system  functions  and,  ultimately,  component  modules  meant  to  accomplish  those  functions. 

Eight  (8)  component  modules  were  identified  and  ranked  in  importance,  with  the  LRS  structure 
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and  LRS  recovery  mechanism  identified  as  the  two  (2)  most  important.  Next,  the  project  team 
identified  technologies,  both  known  and  conceptual,  which  could  fulfill  system  functions  for 
each  of  the  component  modules.  Finally,  these  technologies  were  combined  into  concept 
alternatives,  ranked  according  to  weightings  established  during  the  QFD  process  and 
documented  as  four  (4)  conceptual  alternatives,  which  could  achieve  system  requirements  and 
provide  stakeholder  value.  To  support  comparison  between  the  existing  concepts  and  future 
concepts,  a  baseline  concept  was  identified  to  best  mirror  the  functionality  of  the  Universal 
Launch  and  Recovery  Mechanism  (ULRM),  a  system  previously  integrated  with  submarine 
missile  tubes. 

The  next  step  was  to  assess  the  feasibility  of  each  concept  and  risks  (performance,  cost, 
schedule  and  programmatic)  associated  with  each  concept.  As  done  in  technology  identification, 
the  Capstone  team  used  experience,  lessons  learned  and  peer  recommendations  to  rate  concept 
feasibility  and  assign  risks  and  potential  mitigation  plans.  A  weighted  formula  combined  all 
risks  for  a  given  concept  into  one  value  so  that  concepts  could  be  plotted  against  each  other  on 
one  risk  matrix.  As  the  four  (4)  concept  alternatives  were  deemed  to  perform  better  than  the 
current,  baseline  alternative,  the  baseline  alternative  was  identified  as  the  highest  risk  concept. 
None  of  the  other  alternatives  markedly  separated  themselves  from  one  another  although  the 
Mechanical  Recovery  Arm  alternative  offered  the  lowest  risk  as  the  technology  is  already  used  in 
undersea  environments.  Risk  assessment  is  a  qualitative  exercise  that  can  instill  bias  towards 
certain  solutions.  However,  the  Capstone  team  believed  the  results  of  the  risk  assessment  were 
accurate  based  on  team  members  experience  with  acquisition  and  sustainment  of  similar 
submarine  systems. 
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With  component  concepts  and  allocated  functions  for  each  concept  established,  lifecycle 
costs  were  estimated  for  each  conceptual  alternative.  Using  material  cost  data  from  commercial 
sources  and  labor/production  costs  from  public  shipyards  for  similar  submarine  work,  the 
Capstone  team  established  acquisition  estimates  for  a  single  unit  of  each  alternative.  For 
comparison,  the  team  used  a  cost  data  point  for  a  Multiple  All-Up  Round  Canister  (MAC), 
employed  in  submarine  missile  tubes.  With  acquisition  costs  established,  assumptions  were 
made,  based  on  the  anticipated  reliability  of  each  alternative,  to  create  a  maintenance  plan  over  a 
service  life  of  20  years.  Maintenance  costs  were  detennined  to  be  a  percentage  of  acquisition 
costs  for  each  alternative  and  were  based  on  comparable  maintenance  and  acquisition  costs  of 
submarines  in  a  shipyard  environment.  To  detennine  a  single  lifecycle  cost  in  current  year 
dollars,  out-year  costs  were  multiplied  by  a  discount  factor  and  all  costs  were  summed. 

Cost  analysis  found  that  the  structural  materials  were  the  over-arching  cost  driver  for  all 
alternatives.  Structural  material  costs  accounted  for  between  75%  and  90%  of  the  overall 
acquisition  costs  for  all  considered  alternatives.  As  maintenance  and  sustainment  costs  leverage 
off  of  the  acquisition  costs,  structural  material  costs  contribute  a  significant  amount  of  the  overall 
lifecycle  cost  to  each  concept  alternative.  As  such,  the  Baseline  Alternative,  which  uses  a 
relatively  cheap  high  strength  steel  structural  material,  had  a  lifecycle  cost  of  $16M  less  than  the 
nearest  alternative,  even  with  a  more  extensive  maintenance  and  sparing  plan.  However,  the  use 
of  steel  in  a  seawater  environment  adds  additional  risks  with  respect  to  corrosion  and  component 
failure  as  well  as  adds  weight  and  reduces  payload  volume  to  provide  the  necessary  structural 
strength.  The  titanium  alternatives,  while  considered  the  “soundest”  material  with  respect  to 
structural  strength  per  volume  of  material,  were  also  the  most  costly  alternatives.  Sensitivity 
analysis  and  examination  of  future  titanium  pricing  trends  vice  carbon  fiber  composite  and  high 
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strength  steel  pricing  trends  found  significant  pricing  risks  as  growing  competition  is  expected  to 
deplete  titanium  sponge  resources.  Carbon  fiber  composite  alternatives  provided  a  middle-of- 
the-road  cost  approach  to  the  metallic  alternatives.  Estimates  for  carbon  fiber  capital  equipment 
such  as  molds  and  manufacturing  processes  were  difficult  to  reflect  and  may  skew  current 
estimates  somewhat  higher  than  the  team  estimates  of  $4M  for  initial  capital  costs.  However,  as 
the  raw  materials  for  carbon  fiber  materials  are  inexpensive  and  plentiful,  future  costs  may  trend 
downward  as  manufacturing  processes  improve  and  competition  forces  pricing  consideration. 

As  such,  the  team  considers  life-cycle  pricing  estimates  valid. 

Additionally,  since  raw  material  cost  per  pound  of  carbon  fiber  and  titanium  are  about 
equal  and  since  titanium  weights  twice  as  much  as  carbon  fiber,  a  titanium  structure  was  still 
estimated  to  cost  twice  as  much  to  actually  fabricate.  The  Capstone  team  agreed  that  it  would  be 
possible  to  make  a  titanium  structure  which  weighted  only  !4  as  much  as  a  comparable  carbon 
fiber  structure,  this  detailed  design  analysis  was  beyond  the  scope  of  the  project.  Furthermore, 
making  any  structures  with  hollow  tubes  would  violate  principles  that  restrict  implodable 
volumes  in  submarine  external  compartments  and  would  make  it  much  more  difficult  to  remove 
half  the  weight  from  a  titanium  structure. 

Concurrent  with  cost  analysis,  modeling  and  simulation  was  accomplished  to  analyze  the 
perfonnance  effects  on  the  LRS  concepts  under  a  variety  of  input  conditions.  Using  the  system’s 
top-level  functions  of  “Launch”,  “Recover”,  “Maintain”  and  “Replenish”  as  starting  points,  the 
Capstone  team  generated  a  mission  model  in  ExtendSIM®  designed  to  focus  on  testable  key 
perfonnance  parameters  such  as  launch  and  recovery  success  (as  a  function  of  overall  system 
reliability),  launch  and  recovery  speed  and  system  replenishment  time. 
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Modeling  parameters  for  each  concept  alternative  and  were  derived,  to  the  maximum 
extent  practical,  by  evaluating  the  component  composition  of  each  alternative.  The  team  made 
reliability  and  speed-related  assumptions  using  known  or  derived  values  for  USS  LOS 
ANGELES  CLASS  (SSN  688)  submarine  missile  launch  data  and  commercial  specification  data 
for  similar  products.  Additionally,  to  add  a  sense  of  realism  to  the  mission  model,  the  team  used 
weather  and  sea  traffic  assumptions  for  a  potential  mission  area  (Strait  of  Hormuz). 

Modeling  and  simulation  results  showed  a  mixed  solution.  For  instance,  Alternative  1  - 
Attraction  Recovery,  performed  best  with  respect  to  overall  launch  and  recovery  success 
(reliability)  whereas  Alternative  4  -  Performance  Option,  performed  best  with  respect  to  overall 
cycle  time.  Under  the  Operational  Situation  (OPSIT)  parameters,  Alternatives  1  and  4 
dominated  Alternatives  2,  3  and  the  Baseline  in  all  measures.  However,  down-select  between 
Alternatives  1  and  4  could  not  be  based  simply  on  perfonnance  alone. 

The  perfonnance  models  were  adjusted  to  examine  component  sensitivity  and  the  overall 
validity  of  the  model.  By  selecting  reliability  values  of  between  5%  and  15%  different  from  the 
tolerance  values  established  in  the  perfonnance  input  assumptions,  model  results  still  showed  a 
preference  for  Alternatives  1  and  4.  As  such,  baning  significant  errors  made  in  the  team’s 
selection  of  the  input  assumptions,  the  model  would  be  expected  to  consistently  identify 
Alternatives  1  and  4  as  the  superior  choices.  Also  of  interest,  the  Launch  and  Recovery  system 
overall  reliability  was  set  at  100%  so  that  only  external  factors  (weather,  UUV,  host  submarine) 
would  affect  launch  and  recovery  success.  For  all  alternatives  except  the  Baseline,  mission 
success  was  about  90%,  which  corresponds  fairly  well  with  the  team’s  anticipated  A0  and 
mission  success  rate  derived  from  similar  submarine  functions. 
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Detail  Design  Considerations 

Design  Considerations  qualitatively  assessed  the  risks  associated  with  proceeding  into 
design  and  fabrication  of  the  conceptual  alternatives.  As  the  over- arching  Feasibility  Analysis 
and  Concept  Risk  Analysis  conducted  during  the  Functional  Analysis  Phase,  Design 
Considerations  assessed  the  characteristics  the  LRS  should  possess  to  minimize  negative  cost, 
schedule,  perfonnance  or  programmatic  results.  However,  Design  Considerations  focused  on 
specific  areas,  with  considerable  concentration  on  interfaces,  and  recommended  not  only 
material  concerns  to  mitigate  risks  but  also  procedural  and  planning  steps  necessary  to  help 
remove  risks  from  design,  production,  testing  and  maintenance/support  of  the  LRS. 

The  analysis  looked  at  interfaces  between  internal  and  external  systems.  While  risks 
between  internal  component  interfaces  would  be  managed  through  sound  architecture,  the  team 
found  considerable  issues  are  likely  with  the  internal/external  interfaces.  Unlike  on  SSGN 
submarines,  the  Virginia  Payload  Tubes  (VPT)  on  VA  Class  Block  III  submarine  is  located 
external  to  the  pressure  hull.  Physically  interfacing  the  system  components  inside  the  submarine 
with  those  outside  the  submarine  would  require  hull  penetrator  back-fits  to  both  the  submarine 
and  to  the  VPT.  Hull  penetrators  must  not  only  be  capable  of  transmitting  data,  they  are  also 
required  for  power  replenishment.  Additionally,  the  shape  and  size  of  the  Large  Vehicle  Class 
UUV  and  desired  number  of  UUVs  stowed  in  a  system  will  alter  considerations  for  LRS 
clamping  devices  and  stowage  devices.  The  risks  of  significant  rework  to  the  LRS,  host 
submarine  and  UUV  could  all  be  significantly  mitigated  by  early  and  frequent  communications 
between  all  stakeholders. 

System  Safety  and  Usability  Analysis  and  Logistics  Analysis  examined  potential 
materials/designs  for  concept  alternatives  and  recommended  considerations  to  lessen  the  risks 
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associated  with  fielding  a  successful  system.  While  material  choices  and  design  were  obvious 
considerations  to  eliminate  hazards  and  maintenance  issues,  equally  important  were  human 
factors  and  policy  constraints.  With  technology  advances,  needs  for  skilled  craftsmen  must  be 
identified  early  to  support  maintenance  needs.  Also,  the  unique  submarine  operating 
environment  cannot  support  a  system  that  releases  significant  amounts  of  explosive  gasses  or 
requires  submerged  operations  with  obstructed  hull  closure  devices.  Again,  early  and  frequent 
lines  of  communication  would  be  required  to  mitigate  design  issues. 

Reliability  Analysis  used  block  diagrams  to  represent  different  system  configurations, 
seeking  to  maximize  a  reliability  growth  strategy.  While  a  simple  model  that  places  the  four  top- 
level  system  functions  in  series  results  in  the  lowest  cost  option,  it  also  creates  the  lowest  system 
reliability  output  as  it  is  susceptible  to  a  single-switch  failure.  Noting  that  electronics  and 
software  provide  a  significant  amount  of  functionality  to  the  system’s  “Replenish”  and 
“Maintain”  functions,  the  team  proposed  adding  a  level  of  redundancy  to  these  functions.  These 
additions  would  come  at  an  overall  low  cost,  will  focus  on  system  interface  areas  where  risk  is 
high  and  will  not  add  significant  weight  nor  significantly  reduce  the  payload  volume. 
Furthermore,  as  mission  and  data  functionality/requirements  evolve,  electronic  and  software 
component  alterations  provide  the  best  mechanisms  to  invoke  these  changes  for  minimal  cost. 

As  a  result,  this  alteration  would  result  in  an  overall  system  reliability  of  ~79%  vice  ~66%  for 
system  in  series  (assuming  90%  reliability  for  each  component  package). 

The  Software  Development  Plan,  Test,  and  Evaluation  Strategy  provided  recommended 
guidelines  to  minimize  the  risks  at  final  operational  testing  and  provided  areas  for  technical 
assessment  of  the  system  during  design  and  demonstration.  Both  processes  champion  open 
sourcing  of  materials  to  the  maximum  extent  practical  vice  design-from-scratch.  Both  processes 
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also  recognize  the  need  for  significant  government  oversight  of  contractors  during  development 
and  leveraging  of  unit  testing,  modeling  and  laboratory  demonstration  testing  as  practical.  As 
final  operational  testing  will  employ  a  VA  Class  Block  III  submarine  asset,  integration  of  all 
systems  and  combined  demonstration  /  operational  testing  in  a  test  tank  will  support  the 
necessary  troubleshooting  prior  to  the  final  fielded  event. 

B.  CONCLUSIONS 

Of  the  concept  alternatives  explored,  Alternative  4  (Figure  39)  provides  the  best  value  to 
the  stakeholders  for  the  investment.  Alternative  4  demonstrated  superior  modeling  and 
simulation  perfonnance  times  with  an  acceptable  rate  of  success.  Acquisition  costs  were  mid¬ 
range  while  sustainment  costs  were  comparatively  low  due  to  high  reliability  and  maintainability 
of  the  structure,  redundant  features  and  lack  of  frictional  wear  issues. 

Specific  technologies  for  concept  component  packages  and  the  pros  and  cons  for  the 
technologies  were  based  on  Capstone  team  experience,  discussions  with  peer-groups  and 
available  literature.  Future  technologies  might  result  in  alternative  groupings  that  provide 
superior  value  to  the  stakeholder  at  equal  or  less  investment;  however,  the  Capstone  team 
concludes  that  there  are  several  characteristics  were  keys  to  any  successful  system.  As  shown  in 
Table  27,  Alternatives  2  and  4  offered  similar  use  to  the  stakeholders  and  at  a  similar  investment. 
Characteristics  found  in  these  alternatives,  detailed  below,  offer  a  blueprint  for  a  successful  LRS 
that  could  meet  stakeholder  requirements  and  changes  into  the  future: 

•  Structural  components  are  the  most  significant  cost  driver,  both  in  acquisition  and 
maintenance.  While  a  carbon  fiber  composite  structure  (specified  for  Alternatives  2 
and  4)  offer  weight  reduction,  noise  reduction  and  corrosion  resistance  at  a  stable 
future  price,  issues  with  robustness,  especially  in  torsion,  add  risk  to  the  design. 
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Additionally,  design  changes  may  require  re-molding  of  large  parts  vice  small,  in- 
place  modifications.  Ideal  solutions  should  consider  the  significant  advantages 
composites  offer  and  explore  ways  of  correcting  the  shortfalls.  Potential  solutions 
might  involve  molding  metallic  components  into  the  composites  at  manufacture  to 
provide  a  surface  to  bear  loads  and  a  foundation  for  simple  future  modifications. 

•  Successful  launch  and  recovery  mechanisms  must  be  adaptive  and  must  minimize 
submarine  dwell  time.  UUV  shapes,  sizes  and  material  considerations  make  systems 
that  rely  on  clamps,  magnets  and  sleds  slow  and  restrictive.  Instead,  until  UUV 
technology  produces  a  vehicle  that  matches  speed  with  the  submarine  and 
automatically  maneuvers  to  its  capture  device,  system  should  focus  on  remote  capture 
while  in  motion.  Devices  that  produce  a  low-pressure  pocket  that  draws  the  UUV  to 
the  submarine  or  that  remotely  capture  and  pull  the  UUV  to  the  submarine  offer  the 
most  promise  to  adapt  and  reduce  dwell  time. 

•  Simple  designs  not  only  decrease  risk,  they  also  improve  reliability.  For  the  LRS, 
simple  did  not  mean  devoid  of  technological  advances;  instead,  it  meant  systems  that 
multi-task  and  systems  that  still  function  in  the  event  of  minor  failures.  A 
combination  launch  and  recovery  mechanism  with  similar  mechanical  components 
and  built-in  redundancy  for  the  controls  and  functions  of  the  components  should  be 
considered  as  a  design  solution.  Exploration  of  mechanisms,  which  function  at  or 
near  full  capacity  in  sub-optimal  situations,  such  as  induction  power  replenishment, 
can  reduce  the  reliance  on  other  mechanisms  to  always  operate  without  error. 
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C.  LESSONS  LEARNED 


The  successful  implementation  of  autonomous,  unmanned  systems  into  the  underwater 
battle  space  will  continue  to  challenge  US  Navy  leadership,  technical  experts  and  the  acquisition 
community  for  decades  into  the  future.  As  unmanned  air  vehicles  has  allowed  the  US  military  to 
conduct  around-the-clock  air  surveillance  and  targeting  of  adversaries  with  little  risk  to  military 
personnel  and  manned  assets,  the  UUV  community  will  constantly  be  challenged  to  perfonn 
equally  well  in  deep  sea  and  littoral  environments.  During  the  progression  of  this  Capstone 
project,  several  lessons  learned  were  identified  which  should  be  considered  for  UUV/submarine 
integration  projects  and  studies. 

Requirements  Stability  -  Stakeholders  should  consider  re-visiting  the  mission  and 
operational  parameters  established  for  persistent  -ISR  operations  in  the  2004  UUV  Master  Plan. 
Particular  emphasis  should  be  focused  on  endurance  requirements  for  perceived  missions  and 
whether  it  is  feasible,  in  the  near  term,  to  field  UUVs  launched  from  submarines  to  meet  those 
requirements.  If  not  practical,  stakeholders  might  consider  near-term  mission  guidelines  that 
support  current  capabilities,  such  as  an  incrementally  fielded  approach.  If  endurance 
requirements  established  in  Ashton,  2010,  Anderson  2011  and  Taylor,  2011  are  mandatory, 
fielding  of  multiple  Large  Vehicle  Class  UUVs  in  a  rotational  pattern  might  be  considered  an 
option. 

Submarine/UUV  System  Certification  Issues  -  UUVs  and  their  launch/recovery 
mechanisms  can  pose  a  widespread  and  detrimental  effect  to  the  host  submarine  and  submarine 
personnel.  As  the  UUV  and  launch/recovery  equipment  are  stowed  within  boundaries  of 
contained  submarine  structure,  toxic,  flammable  and  explosive  materials  can  result  in 
catastrophic  effects  where  similar  materials  used  in  unmanned  air  or  ground  vehicles  may  pose 
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little  to  no  issues.  Additionally,  equipment  weight,  launch  and  separation  reliability,  shock 
resistance  and  flood  control  measures  affect  the  host  submarine  in  ways  not  shared  by  other 
unmanned  vehicle  host  platforms. 

While  governing  ASTM  guides  provide  guidelines  for  the  capabilities  of  UUVs,  they  do 
not  specifically  address  constraints  related  to  submarine  launch  and  recovery  platforms.  US 
Navy  leadership  needs  to  recognize  that  submarine  launched  and  recovered  UUVs  are  a  family 
of  systems  with  constraints  unique  to  land-based  systems.  Integration  issues,  particularly  those 
related  to  submarine  safety  issues,  require  early  and  on-going  teaming  between  the  stakeholders 
of  the  two  primary  external  boundary  systems. 

Modularity/Flexibility  -  UUV  manufacturers  continue  to  explore  technologies  meant  to 
break  through  constraints  that  limit  current  capabilities.  Many  of  these  technologies,  such  as  fuel 
cells  and  increasingly  autonomous  controls  may  not  be  mature  enough  to  support  a  fielded  unit 
for  5  or  more  years  into  the  future.  However,  when  successfully  implemented,  they  stand  to 
dramatically  change  the  way  a  UUV  would  be  integrated  with  a  submarine.  For  instance,  UUV 
diameter  and  length  would  be  significantly  larger  to  accommodate  large  energy  sources.  In 
addition,  re-fueling  may  come  in  a  fonn  of  a  gas  or  liquid  vice  electricity,  or,  in  some  cases,  may 
not  be  required  at  all.  To  support  these  incremental  changes  to  UUV  size,  make-up  and 
capabilities,  future  studies  should  focus  on  the  flexibility  and/or  modularity  of  a  launch  and 
recovery  system.  Trade-off  studies  might  examine  components,  which  could  effectively  be 
modified  vice  completely  re-designed  to  accommodate  change.  Close  relationships  with  UUV 
designers  and  manufacturers  would  be  required  to  support  plausible  visions  into  the  future  while 
limiting  sacrifices  to  perfonnance  and  acquisition  costs. 
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APPENDIX  A  -  PROJECT  MANAGEMENT  PLAN  ROLES  AND 

RESPONSIBILITIES 


This  appendix  provides  specific  details  with  respect  to  the  team’s  roles,  responsibilities, 
actions  and  deliverables  related  to  the  work  on  this  capstone  project. 


Project  Team  Organization 

The  UUV-ISR  project  team  was  organized  in  accordance  with  Figure  1  below: 


Figure  1  -  UUV-ISR  Project  Team  Organization 

The  UUV  ISR  project  team  consists  of  seven  engineers,  all  employed  by  Naval  Sea 
Systems  Command  (NAVSEA)  and  co-located  at  the  Washington  Navy  Yard.  Combined,  the 
team  possesses  80  years  of  experience  on  submarine  design,  operation,  maintenance  and 
sustainment.  Engineering  experience  of  team  members  is  general  and  broad  in  nature.  No 
member  of  the  team  is  a  Subject  Matter  Expert  on  a  specific  area  or  technology  that  relates  to 
this  analysis. 

Due  to  co-location  of  team  members  and  broad  vice  specialized  area  of  expertise,  the  use 
of  Integrated  Project  Teams  will  not  be  employed  for  this  project.  Instead,  all  team  members 
will  participate,  in  general,  on  all  aspects,  with  individual  team  members  assigned  leads  for  the 
identified  roles  and  responsibilities.  Additionally,  due  to  small  team  size,  most  members  will  be 
dual-hatted  and  serve  more  than  one  team  role.  Table  1  is  a  listing  of  each  team  member’s 
primary  roles  and  responsibilities.  Roles  and  responsibilities  are  subject  to  change  as  the  project 
progresses  and  needs  arise. 
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Table  1  -  UUV  Team  Members  Roles  &  Responsibilities 


Name 

Roles  &  Responsibilities 

Locat 

ion 

Calvert,  Bill 

Project  Lead,  Assistant  to  Editor-in-Chief,  Secretary 

NAVSEA 

Malecki,  Sarah 

Deputy  Project  Lead,  Editor-in-Chief,  Secretary 

NAVSEA 

Goodman,  Gail 

Scheduler,  System  Engineer  and  Architect,  Secretary 

NAVSEA 

Lojek,  Joe 

Cost  and  Business  Advocate,  Secretary 

NAVSEA 

Powell,  Brian 

Modeling  &  Simulation,  Secretary 

NAVSEA 

Heidt,  Brian 

Librarian  (Configuration  Manager),  Assistant  to  Modeling  & 
Simulation,  Secretary 

NAVSEA 

Cohn,  Rachel 

Risk  Manager,  Secretary 

NAVSEA 

Project  Lead 

The  project  lead  is  responsible  of  overall  management  and  execution  of  the  project  in 
accordance  with  the  project  management  plan.  The  lead  will  develop  the  agenda  for  team 
meetings,  conduct  team  meetings,  coordinate  action  items  and  assign  due  dates.  The  lead  will 
ensure  the  balance  of  resources  was  adequately  distributed  to  support  the  technical  abilities  of  the 
team  members  and  support  the  scheduled  delivery  of  technical  products.  The  lead  will  serve  as 
the  primary  Point-of-Contact  (POC)  with  the  project  advisors. 

Deputy  Project  Lead 

The  deputy  project  lead  will  assume  the  duties  of  the  project  lead  in  their  absence  and 
will  serve  as  a  secondary  POC  with  project  advisors. 

Secretary 

The  secretary  is  a  rotating  position  that  will  be  assigned  at  each  team  meeting.  The 
secretary  will  be  responsible  for  the  creation  and  distribution  of  meeting  minutes  for  the  team,  to 
include  action  items  and  due  dates  assigned  as  a  result  of  team  meeting  discussions.  The 
secretary  will  maintain  the  project  engineering  journal  for  the  team,  submitted  to  the  secretary  by 
all  team  members,  as  practical,  on  a  weekly  basis. 

Librarian 

The  librarian  is  the  Configuration  Manager  (CM)  for  the  project  team  and  will  be 
responsible  for  the  communications  plan  for  the  team.  The  librarian  will  maintain  an  auditable 
trail  of  documentation  and  will  enforce  version  control  to  project  deliverables  per  the  details  of 
the  communications  plan.  The  librarian  will  provide  means  and  traceability  for  performance  and 
effectiveness  of  alternate  system  designs  back  to  stakeholder  requirements. 

System  Engineer  and  Architect 

The  system  engineer/architect  is  responsible  for  defining  and  implementing  the  systems 
engineering  approach  to  the  development  of  the  project.  The  system  engineer/architect  will 
serve  as  project  team  lead  for  stakeholder  requirements  definition,  requirements  analysis  and 
architectural  design  for  the  proposed  system.  The  system  engineer/architect  will  lead 
establishment  of  system  Measurements  of  Effectiveness  (MOE)  and  Measurements  of 
Performance  (MOP)  necessary  to  evaluate  alternate  design  options.  The  system 
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engineer/architect  will  support  functional  and  process  decomposition  of  operational  activities  and 
will  develop  input  requirements,  functions,  components  and  relationships  necessary  to  develop 
the  system  architecture. 

Modeling  &  Simulation 

The  modeling  and  simulation  (M&S)  lead  is  responsible  for  development  and 
implementation  of  functional  performance  models  and  operational  performance  models  as  means 
to  compare  the  perfonnance  and  effectiveness  of  various  system  alternatives.  The  M&S  lead 
will  provide  verification  and  validation  of  models  to  stakeholder  requirements  and  will  provide 
analysis  of  simulation  results  to  support  trade  space  analysis. 

Scheduler 

The  scheduler  will  develop  the  project  schedule  and  track  progress  versus  planned  due 
dates.  The  scheduler  will  maintain  and  active,  real-time  model  of  the  project  schedule,  available 
to  all  team  members  and  will  establish  critical  path  functions  requiring  the  attention  of  all  team 
members. 


Cost  and  Business  Advocate 

The  cost  and  business  advocate  will  develop  models  to  analyze  the  Life-Cycle  Costs 
(LCC)  that  assess  the  affordability  of  various  system  alternatives.  The  advocate  will  utilize  Cost 
as  an  Independent  Variable  (CAIV)  to  support  cost-benefit  analysis  for  potential  system 
alternatives.  The  advocate  will  have  the  lead  responsibility  to  generate  estimated  life-cycle  costs 
of  alternatives  using  historical  data,  standard  parameters  or  like  comparisons  with  similar 
components,  processes  and  procedures. 

Editor-in-Chief 

The  editor-in-chief  is  responsible  for  development  and  delivery  of  technical  documents 
for  the  project  team.  The  editor-in-chiefs  responsibilities  include  fonnatting,  spelling/grammar, 
and  establishing  the  cohesiveness  of  the  technical  documents  from  the  submittals  of  the  various 
team  members.  The  editor-in-chief  will  utilize  the  text  recommended  by  project  advisors  for 
development  of  the  team’s  technical  documents. 

Risk  Manager 

The  risk  manager  will  assess  potential  areas  of  technical,  schedule  and  cost  risks 
associated  with  system  requirements  and  project  implementation.  The  risk  manager  will  develop 
assessment  of  risks,  recommend  actions  associated  with  avoidance,  assumption,  transfer  or 
mitigation  of  risks  and  manage  actions  related  to  reduction  of  risks.  Risk  Management  and 
Analysis  will  be  conducted  in  accordance  with  the  Risk  Management  Guide  for  Department  of 
Defense  (DoD)  Acquisition  and  NAVSEA  Instruction  (NAVSEAINST)  5000.8,  Naval  Systems 
Command  (SYSCOM)  Risk  Management  Policy  of  21  July  2008. 

Project  Advisors 

The  UVV-ISR  project  team  advisors  are  Dr.  Jeffery  Beach  and  Professor  Mike  Green. 
Both  are  Naval  Post-Graduate  School  (NPS)  faculty  members  in  the  Department  of  Systems 
Engineering.  In  addition,  Professor  Green  is  an  experienced  submariner. 
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Project  Team  Configuration  Management  Plan 

The  UUV-ISR  Team  Configuration  Management  Plan  (CMP)  provides  guidelines  for  the 

UUV-ISR  project.  The  CMP  covers  five  aspects  of  the  UUV-ISR  project:  Electronic  Files, 

Communications,  Meetings,  Classroom  Data  and  Information  Distribution. 

Electronic  Files 

A.  Document  Repository: 

The  UUV  project  will  use  Google  Docs  as  an  online  document  repository  for  files 
and  infonnation  relevant  to  the  project.  Each  team  member  will  have  access  to  the 
Google  Docs  site  and  obey  the  configuration  management  guidelines  outlined  in  this 
plan.  A  group  account  has  been  set  up  to  allow  individual  group  members  or  advisors  to 
access  the  Google  Docs  site. 

Username:  NPSTeamA 

Password:  NPScapstone 

Once  a  file  has  been  posted  to  the  Google  Docs  site,  the  team  member  responsible 
for  posting  the  file,  will  send  out  an  email  notification  (via  Google  Docs)  to  the  Team  and 
if  necessary  Team  Advisors,  with  any  pertinent  messages  on  the  file. 

B.  File  Naming  Convention: 

All  electronic  files  supporting  the  UUV  project  completion  effort  are  grouped  into 
10  categories  (represented  as  folders  on  the  Google  Docs  site):  Archive,  Class  Chat 
box,  CORE,  Engineering  Notebook,  ExtendSim,  Final  Report,  Interim  Assignments, 
IPR#2,  Meeting  Minutes,  and  References.  All  files  are  given  the  following  naming 
convention: 

“filename. yy.mm.dd.rev”  -  example,  the  first  revision  of  the  Project  Management 
Plan  written  on  October  1 1,  2010  would  be  titled:  “UUV  Project  Management 
Plan.  1 1 .10.10.0”.  Subsequent  revisions  on  the  same  day  would  be  titled  ““UUV  Project 
Management  Plan.  1 1 .10.10.1”  and  “UUV  Project  Management  Plan.  1 1 . 10. 10.2”  etc. 

If  a  new  revision  is  posted  on  a  subsequent  date,  the  filename  description  does  not 
change,  only  the  date  and  revision  change. 

C.  Working  Copies: 

To  prevent  two  team-members  working  off  of  the  same  draft  simultaneously,  the 
latest  working  entry  will  be  titled  “fileanme.yy.mm.dd.rev.working”.  The  “.working” 
indicates  that  active  changes  are  being  made  to  the  latest  revision,  and  other  team 
members  should  not  attempt  to  make  changes.  The  “.working”  file  can  be  a  dummy 
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document  only  used  as  a  posted  placeholder  to  indicate  that  a  team-member  is  modifying 
the  latest  document.  This  posting  will  be  made  as  soon  as  modification  starts.  The 
“.working”  file  will  be  deleted  once  the  new  revision  has  been  completed  and  posted. 

D.  E-Mail  Policies: 

To  prevent  clogging  and  overloading  of  email  inboxes,  electronic  project  files  will 
not  be  emailed  to  other  team  members.  All  electronic  files  will  be  posted  to  their 
appropriate  folder  on  the  designated  team  site. 


Communications 

Team  communications  will  take  place  via  four  (4)  mediums:  E-mail,  telephone, 
Elluminate  sessions,  and  in-person  meetings. 

E-Mail:  To  maintain  configuration  control  of  group  discussions,  e-mail  shall  not 
be  used  for  group  discussions  or  comments.  Group  e-mail  will  only  be  used  for  file 
posting  notification  and  meeting  announcements.  One  group  representative  will  engage 
professors/advisors  via  email  and  post  relevant  responses  on  Google  Docs.  Other  group 
members  will  not  be  included  on  the  “cc”  or  “bcc”  fields  of  these  emails. 

Telephone:  If  the  team,  or  select  individuals,  participates  in  a  teleconference  or 
telephone  call,  the  minutes  or  results  of  the  conversation  shall  be  posted  to  the  “meeting 
minutes”  folder  on  Google  Docs. 

Elluminate:  When  the  group  engages  in  meetings  via  Elluminate,  the  session 
shall  be  recorded  and  posted  (if  possible)  to  the  “meeting  minutes”  folder  on  Google 
Docs.  If  the  file  was  not  recorded,  or  if  posting  is  not  possible,  minutes  shall  be  recorded 
and  posted  to  the  meeting  minute’s  folder. 

In-Person  Meetings:  Face  to  face  meetings  will  be  scheduled  via  email  in  the 
form  of  a  meeting  request.  Minutes  will  be  recorded  and  posted  to  the  “meeting  minutes” 
folder. 


Meetings 

Meetings  will  be  scheduled  by  the  team  scheduler  and  attended  by  as  many  team 
members  as  possible. 

Regular  team  meetings  are  scheduled  for  Tuesdays,  1530  to  1700,  EST. 
Elluminate  meetings  with  Project  Advisors  are  scheduled  for  Wednesdays,  1800  to  1900, 
EST.  Other  meetings  as  necessary  will  be  scheduled  by  the  designated  team  scheduler. 

Minutes  will  be  recorded  at  every  team  meeting.  Minutes  should  include  team 
members  in  attendance,  guests,  time  and  date  of  meeting  and  any  action  items  from  the 
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meeting.  Meeting  minutes  will  be  posted  to  the  “meeting  minutes”  no  more  than  24  hours 
after  a  team  meeting,  when  practical. 


If  any  action  items  are  assigned  at  team  meetings,  the  action  shall  be  written  down 
in  full,  as  well  as  the  team  member  the  action  is  assigned  to  and  the  date  the  action  is  to 
be  completed.  Action  items  will  be  included  in  the  meeting  minutes. 

Meetings  will  take  place  in  one  of  three  venues,  In-person,  Telephone  Conference 
or  via  Elluminate  session. 


Class  Data 

Class  data  captures  the  Monday  Elluminate  session,  if  held. 

A  recording  of  each  Elluminate  session  will  be  made  and  if  possible  posted  to  the 
“meeting  minutes”  folder  on  Google  Docs.  If  this  is  not  possible,  then  the  default  session 
location  on  Elluminate  will  suffice. 

A  team  member  will  be  responsible  for  copying  the  entire  class  chat  window  from 
every  Monday  Elluminate  session  and  posted  as  a  separate  file  to  the  “class  chat  box” 
folder  on  Google  Docs. 


Information  Distribution 

All  data  will  be  taken  from  and  released  as  Distribution  A  (available  for  public 
release).  This  project  will  not  use  any  data  from  distribution  sources  other  than 
Distribution  A  unless  prior  consent  is  gained  by  the  appropriate  classification  agency. 
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Project  Deliverables 


Table  2  outlines  the  deliverables  and  milestones  associated  with  the  proposed  project. 
Prior  to  satisfactorily  completing  a  milestone,  all  deliverables  must  be  satisfied  per  review  by  the 
UUV-ISR  team  and  the  system’s  active  stakeholders. 


Table  2  -  Deliverables  &  Milestones 


Deliverable  and  Milestone 

Approx.  Completion  Date 

Final  Project  Management  Plan  Submitted 

28  Oct  2010 

NPS  SE  Chair  Approves  Project  Management  Plan 

19  Nov  2010 

In-Process  Project  Advisor  Review  No.  1 

6  Dec  2010 

In-Process  Project  Advisor  Review  No.  2 

14  Mar  2011 

Final  Capstone  Report  Draft  Submitted 

11  May  2011 

Final  Reviewed  and  Concurred  Report  Submitted 

1  June  2011 

Final  Capstone  Briefing  Accomplished 

6  June  2011 

Project  Risk  Management  Plan 
Purpose 

The  purpose  of  the  Risk  Management  Plan  (RMP)  is  to  outline  the  strategy  that  will  be 
followed  to  manage  risk  within  the  team’s  program.  Risk  is  a  measure  of  future  uncertainties  in 
achieving  program  performance  goals  and  objectives  within  defined  cost,  schedule,  and 
perfonnance  constraints. 

The  RMP  will  not  identify  or  address  specific  risks,  but  rather  will  serve  as  general 
guidance  and  instruction.  Individual  risks  will  be  identified  and  managed  in  a  working  document 
titled  Risk  Analysis  Document. 

Risk  Management  Plan  Process  Model 

The  Risk  Management  Process  Model,  as  described  in  the  Risk  Management  Guide  for 
DoD  Acquisition,  consists  of  five  activities:  risk  identification,  risk  analysis,  risk  mitigation 
planning,  risk  mitigation  plan  implementation,  and  risk  tracking,  as  illustrated  in  Figure  2,  which 
are  performed  on  a  continuous  basis,  throughout  a  system’s  life  cycle. 
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Figure  2  -  DoD  Risk  Management  Process 
Risk  Management  Activities 

Risk  Identification:  Risk  identification  is  the  activity  during  which  each  element  of  our 
program  will  be  examined,  in  order  to  identify  risk  root  causes,  so  that  appropriate  action  can  be 
taken  to  manage  them.  All  team  members  will  participate  in  identifying  risk  root  causes  on  an 
ongoing  basis.  Risks  will  be  identified  by: 

•  Looking  at  current  and  proposed  staffing,  design,  resources,  etc. . . 

•  Reviewing  potential  shortfalls  against  expectations 

•  Monitoring  results  of  testing  and  simulation 

•  Analyzing  negative  trends 

Figure  3  is  a  risk  breakdown  structure,  in  which  risk  is  decomposed  into  categories.  This 
is  a  helpful  tool  in  identifying  root  causes. 

Risk  Analysis:  During  the  risk  analysis  activity,  we  will  determine  how  significant  a  risk 
is  by  determining  the  likelihood  of  the  root  cause  occurrence,  and  identifying  possible 
consequences  if  the  root  cause  were  to  occur.  This  information  will  be  used  to  plot  each  risk  in  a 
Risk  Reporting  Matrix,  Figure  4. 

The  level  of  likelihood  of  each  root  cause  is  established  using  the  table  shown  in  Figure 
5,  and  the  level  of  consequence  of  each  root  cause  is  established  using  the  table  show  in  Figure  6. 
When  categorizing  the  level  of  consequence  for  a  root  cause,  we  will  first  identify  if  the  primary 
consideration  is  perfonnance,  schedule,  or  cost.  Thus,  if  the  primary  consequence  of  a  root  cause 
is  a  significant  degradation  in  technical  performance,  but  the  cost  and  schedule  are  not  impacted 
considerably,  then  the  level  of  consequence  for  this  root  cause  shall  be  a  four  (4).  Low  levels  of 
risk  are  reported  in  green,  moderate  risks  are  in  yellow,  and  high  risks  are  in  red  on  the  Risk 
Reporting  Matrix. 
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Risk  Mitigation  Planning:  During  the  risk  mitigation  planning  phase,  the  team  shall 
develop  an  approach  to  address  each  risk.  Options  for  mitigating  risk  include: 

•  Avoiding  risk  by  eliminating  the  root  cause  and/or  consequence 

•  Controlling  the  cause  or  consequence 

•  Transferring  the  risk 

•  Assuming  the  level  of  risk  and  continuing  on  the  current  program  plan. 

Note  that  assuming  the  level  of  risk  will  not  be  an  acceptable  option  for  moderate  and 
high  risks. 

The  following  topics  will  be  addressed  and  documented  for  each  identified  risk  in  the 
Risk  Analysis  Document: 

•  Descriptive  risk  title 

•  Description  of  risk,  to  include  a  summary  of  impacts,  likelihood  of  occurrence, 

consequence,  and  whether  the  risk  is  within  the  control  of  the  program 

•  Root  causes  leading  to  the  risk 

•  Mitigation  options 

•  Events  and  activities  intended  to  reduce  risk,  and  subsequent  level  of  risk  if  successful 

•  Recommendation  for  mitigation 

•  Resource  needs 

Risk  Management  Plan  Implementation:  During  the  risk  mitigation  plan  implementation 
phase,  the  chosen  risk  mitigation  strategy  identified  in  the  previous  phase  shall  be  executed.  Risk 
reporting  requirements  for  on-going  monitoring  shall  also  be  identified. 

Risk  Tracking:  The  risk  tracking  phase  shall  be  implemented  to  ensure  successful  risk 
mitigation.  This  will  be  done  by  monitoring  risk  mitigation  plans,  reviewing  regular  status 
updated,  and  reviewing  program  metrics  as  applicable. 

Risk  tracking  shall  be  conducted  on  a  periodic  basis  throughout  the  length  of  the 
program.  Known  risks  shall  be  reevaluated  to  account  for  the  updated  information,  and  the 
program  shall  be  examined  for  new  root  causes. 

Responsible  Organizations 

All  team  members  will  play  an  active  role  in  risk  management.  Primary  responsibility  for 
risk  management  shall  belong  to  the  Risk  Manager.  The  Risk  Manager  will  be  in  charge  of 
creating  and  updating  the  Risk  Analysis  Document.  All  team  members  will  contribute  to  the  risk 
identification  phase.  The  Risk  Manager  will  be  the  lead  for  risk  analysis,  risk  identification,  and 
risk  mitigation  planning.  Team  members  may  be  asked  for  input  during  these  activities,  and  will 
review  the  Risk  Analysis  Document  for  accuracy.  Team  members  will  implement  the  risk 
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mitigation  strategies  identified.  The  Risk  Manager  shall  track  risk  based  on  input  from  team 
members. 
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Figure  3  -  Risk  Breakdown  Structure 


Consequence 


Figure  4  -  Risk  Reporting 
Matrix 


Level 

Likelihood 

Probability  of  Occurrence 

1 

Not  Likely 

-10% 

2 

Low  Likelihood 

-30% 

3 

Likely 

-50*/. 

4 

Highly  Likely 

-70% 

5 

Near  Certainty 

-90*/. 

Figure  5  -  Levels  of  Likelihood  Criteria 
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Level 

Technical  Performance 

Schedule 

Cost 

i 

Minimal  or  no  consequence  to  technical 
performance 

Muumal  or  no  impact 

Mmunal  or  no 
impact 

2 

Minor  reduction  in  technical  performance  or 
supponabilny.  can  be  tolerated  wi±  little  or  no 
impact  on  program 

Able  to  meet  key  dates 

Slip  *  month!  s) 

Budget  increase  or 
uni:  production  cost 
increases. 

<  «*  AH  of 
Budget) 

3 

Moderate  reduction  m  technical  performance  or 
suppartabiliiy  with  limited  impaa  on  program 
objectives 

Minor  schedule  slip.  Able 
to  meet  key  milestones 
with  no  schedule  float. 

Shp<  *  month!  s) 

Sub-system  slip  >_^ 
month!.)  pins  available 
float. 

Budget  increase  or 
unit  production  cost 
increase 

<  ♦»  (SHof 
Budget) 

4 

Significant  degradation  m  technical  performance  or 
major  shortfall  in  suppartabihty.  may  jeopardize 
program  success 

Program  cnhcal  path 
affected. 

Slip  <  months 

Budget  increase  or 
unit  pcoducnoa  cost 
increase 

<  ♦»  (lOfto  of 
Budget) 

5 

Severe  degradanon  in  technical  performance: 

C armor  meet  KPP  or  key  techmcal  suppartabihty 
threshold:  will  jeopardize  program  success 

C  annot  meet  key  program 
milestones 

Sln>>  *  months 

Exceeds  APB 
threshold 

>  «*  (lQfto  of 
Budget) 

Figure  6  -  Levels  of  Consequence  Criteria 
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The  Work  Breakdown  Structure  (WBS)  presented  here  is  the  most  current  revision  at  the 
time  of  submission  of  this  document.  The  WBS  will  be  handled  as  a  separate  document  to  be 
updated  throughout  the  project. 

1 .  Unmanned  Undersea  Vehicle/Submarine  Integration  Project 

1.1  Initiate  Project 

1.1.1  Establish  Team  Roles  and  Responsibilities 

1.1.2  Establish  Team  Communication/Configuration  Management  Approach 

1.1.3  Identify  Stakeholders/Subject  Matter  Experts  (SME)  in  Sphere  of  Influence 

1.1. 3.1  Interview  Stakeholders/SME  and  Document  Meeting  Minutes 

1.1. 3.2  Document  Key  Stakeholders  and  Proposed  Needs 

1.1.4  Establish  Capability  Need,  Scope  and  Objective  of  Project 

1.1. 4.1  Document  Need/Scope/Objective  to  Advisors 

1.1.5  Establish  System  Engineering  Approach 

1.1.6  Establish  Risk  Management  Approach 

1.1.7  Develop  Project  Management  Plan  (PMP)  to  Codify  Project  Approaches 

1 . 1 .7. 1  Obtain  Department  Chair  Approval  of  PMP  (Deliverable) 

1.2  Conduct  Requirements  Analysis  &  Verification  Phase 

1.2.1  Compile  Capability  Gaps/  Needs  from  SME  Interviews 

1 .2.2  Compile  Capability  Gaps/Needs  from  Literature  Research 

1 .2.2. 1  Establish  Proposed  Project  Requirements  and  KPPs/KSAs 

1 .2.3  Conduct  Requirements  Trade-off  Assessments 

1 .2.4  Verify  Requirements  to  SME  and  Literature  Research  Gaps/Needs 

1 .2.5  Document  Ranked  Project  Requirements  and  KPP/KSAs 

1 .2.6  Define  Project  Risks  and  Feasibility 

1.2.7  Define  Mission  Capabilities  and  Operational  Activities 

1.2.8  Define  Proposed  Scenarios  for  System 

1.2.8. 1  Document  Proposed  Measures  of  Mission  Success  (MOE  and  MOP) 

1 .2.9  Establish  Preliminary  Final  Report  Outline 

1 .2. 10  Conduct  Interim  Progress  Brief  #1  of  1st  QTR  Work  (Deliverable) 

1.3  Conduct  Functional  Analysis  &  Verification  Phase 

1.3.1  Define  Hierarchy  and  Decompose  System  Architecture 

1.3. 1.1  Document  System  Architecture  into  CORE 

1.3. 1.2  Identify  System  Interfaces/Assess  Risks 

1 .3.2  Develop  Functional  and  Behavioral  Models  of  System 

1.3. 2.1  Conduct  Trade-offs  of  MOE  &  MOP 

1 .3.2. 1 . 1  Document  Final  MOE  &  MOP  and  Metric  for  Measurements 

1 .3.3  Verify  MOE  &  MOP  Support  Stakeholder  Needs 

1.3.4  Using  Top  Level  Architecture  (Functions),  Conduct  QFDs 

1.3. 4.1  Document  Alternatives  (Morphological  Matrix) 
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1.3.5  Conduct  Scoring  to  Identify  Top  Alternatives 

1.3. 5.1  Conduct  Design  Trade-off  Analysis  and  Assessments 

1.3. 5.2  Establish  Value  and  Worth  Scoring  for  Stakeholders 

1.3. 5. 3  Define  Concept  Alternative  Risks  and  Feasibility 

1.3. 5. 4  Establish  Life-Cycle  Cost  Estimates  for  Top  Alternatives 

1.3. 5. 5  Model  and  Simulate  OPSITs  for  Alternatives 

1 .3.5.5. 1  Detennine  MOE  &  MOP  Measurements  for  Alternatives 

1 .3. 5. 5. 2  Perfonn  Modeling  of  Alternative  Functions 

1 .3. 5. 5. 3  Perfonn  LRS  Sensitivity  Analysis 

1 .3.6  Conduct  Team  System  Functional  Review 

1 .3.7  Conduct  Interim  Progress  Brief  #2  of  2nd  QTR  Work  (Deliverable) 

1.4  Conduct  Design  Synthesis  &  Verification 

1 .4. 1  Conduct  Cost-Benefit  Analysis 

1.4. 1.1  Detennine  CAIV 

1 .4.2  Conduct  Interface  And  Design  Analysis 

1.4. 2.1  Develop  Test  Strategy 

1.4. 2.2  Develop  Hardware/Software  Integration  Plan 

1.4. 2. 3  Assess  Safety  and  Usability 

1.4. 2.4  Assess  Logistics  Support 

1.4.3  Conduct  Reliability  Analysis 

1 .4.4  Propose  Final  Design  Recommendation 

1.4.5  Validate  Final  Design  Recommendation  with  Stakeholder  Requirements 

1.4.6  Detennine  Future  Exploration  Avenues 

1.5  Project  Conclusion 

1.5.1  Complete  Draft  Final  Report 

1.5. 1.1  Submit  to  SE  Department  Advisors  and  Secretary  for  Review  (Deliverable) 

1 .5.2  Adjudicate  Comments  and  Submit  Final  Project  Report  (Deliverable) 

1 .5.3  Develop  Project  Presentation 

1.5. 3.1  Deliver  Project  Presentation  for  Faculty  and  Stakeholders  (Deliverable) 
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ID 

a 

Task 

Mode 

Task  Name 

Duration 

Start 

Finish 

1 

V# 

Unmanned  Undersea  Vehicle/Submarine  Integration  Project 

200  days  Mon  9/13/10  Wed  6/15/11 

2 

Initiate  Project 

43  days  Mon  9/13/10  Tue  11/9/10 

3 

v'- if* 

Establish  Team  Roles  and  Responsibilities 

6  days  Mon  9/13/10  Mon  9/20/10 

4 

V'" 

* 

Establish  Team  Common  icatiorV Configuration 
Management  Approach 

6  days  Mon  9/20/10  Mon  9/27/10 

S 

t 

* 

Identify  StakeholderVSubject  Matter  Experts  (SME)  in 
Sphere  of  Influence 

16  days  Mon  9/20/10  Sun  10/10/10 

6 

V 

V* 

Interview  Stakeholders/SME  and  Document  Meeting 
Minutes 

6  days  Mon  9/20/10  Mon  9/27/10 

7 

V  * 

Document  Key  Stakeholders  and  Proposed  Needs 

16  days  Mon  9/20/10  Sun  10/10/10 

8 

v  A* 

Establish  Capability  Need,  Scope  and  Objective  of  Project 

17  days  Sun  10/10/10  Sat  10/30/10 

9 

v'"  A 

Document  Need/Scope/Objective  to  Advisors 

7  days  Sun  10/10/10  Sun  10/17/10 

10 

Establish  System  Engineering  Approach 

9  days  Tue  10/12/10  Fri  10/22/10 

11 

v  "  ^ 

Establish  Risk  Management  Approach 

12  days  Sun  10/17/10  Sat  10/30/10 

12 

v' 

Develop  Project  Management  Plan  (PMP)  to  Codify 
Project  Approaches 

23  days  Sun  10/10/10  Tue  11/9/10 

13 

v'‘ 

> 

Obtain  Department  Char  Approval  of  PMP 
(Deliverable) 

1  day  Tue  11/9/10 

Tue  11/9/10 

14 

V  * 

Conduct  Requirements  Analysis  &  Verification  Phase 

37  days 

Fri  10/15/10 

Mon  12/6/10 

15 

V  ^ 

Compile  Capability  Gaps/  Needs  from  SME  Interviews 

12  days 

Fri  10/15/10  Sat  10/30/10 

16 

V  V* 

Compile  Capability  Gaps/Needs  from  Literature  Research 

12  days 

Fri  10/15/10  Sat  10/30/10 

17 

v'  >/*• 

Establish  Proposed  Project  Requirements  and 
KPPs/KSAs 

7  days 

Fri  10/22/10 

Sat  10/30/10 

18 

Conduct  Requirements  Trade-off  Assessments 

7  days  Sat  10/30/10  Sat  11/6/10 

19 

v'" 

Verify  Requirements  to  SME  and  Literature  Research 
Gaps/Needs 

6  days 

Fri  11/5/10  Fri  11/12/10 

20 

v' 

A- 

Document  Ranked  Project  Requirements  and  KPP/KSAs 

12  days 

Sat  10/30/10  Mon  11/15/1C 

21 

v'  "  ^ 

Define  Project  Risks  and  Feasibility 

9  days 

Wed  ll/10/10Sat  11/20/10 

22 

v'-  A* 

Define  Mission  Capabilities  and  Operational  Activities 

19  days 

Fri  10/15/10  Wed  11/10/1G 

23 

v'  "  ^ 

Define  Proposed  Scenarios  for  System 

17  days 

Frill/12/10  Mon  12/6/10 

24 

v'- 

vt 

Document  Proposed  Measures  of  Mission  Success 
(MOE  and  MOP) 

17  days 

Frill/12/10  Mon  12/6/10 

25 

v'** 

Establish  Preliminary  Final  Report  Outline 

12  days  Fri  10/15/10  Sat  10/30/10 

26 

v" 

Ah 

Conduct  Interim  Progress  Brief  #1  of  1  st  QTR  Work 
(Deliverable) 

1  day 

Mon  12/6/10  Mon  12/6/10 

27 

V' 

Conduct  Functional  Analysis  &  Verification  Phase 

91  days 

Mon  12/6/10  Mon  4/11/11 

28 

A  A* 

Define  Hierarchy  and  Decompose  System  Architecture 

30  days  Mon  12/6/10  Fri  1/14/11 

29 

v*  ib 

Document  System  Architecture  into  CORE 

30  days  Mon  12/6/10  Fri  1/14/11 

30 

AA> 

Identify  System  Interface^ Assess  Risks 

11  days  Sat  1/1/11  Fri  1/14/11 

August 


I  September  I  October  I  November  1  December  I  January  I  February  March 


Apni 


7/2S  1  8/15  I  9/5  I  9/26  i  10/17  I  11/7  I  11/28  I  12/19  I  1/9  I  1/30  1  2/20  i  3/13  i  4/3 


f 


11/9 


C3 


V  12/6 

V 


Project:  UUV_Schedule_ll.04.19. 
Date  Tue  4/19/11 


Task 

Split 

Milestone 

Summary 


Project  Summary 


i  •  1 1 1 1 1 M 1 1 1 1 1 1 1 1 1 1  External  Tasks 
♦  External  Milestone 

V  inactive  Task 


^  inactive  Milestone 
inactive  Summary 
Manual  Task 
□  Duration-only 


O 

V= 


Manual  Summary  Rollup  cs 
^  Manual  Summary 
□  Start-only 
Finish-only 


=a  Deadline 
*9  Progress 


C 

3 


Page  1 


168 


ID 

[Task 

0  Mode 

Task  Name 

Duration 

Start 

Finish 

31 

-K* 

Develop  Functional  and  Behavioral  Models  of  System 

20  days 

Wed  12/15/lCTue  1/11/11 

32 

Conduct  Trade-offs  of  MOE  &  MOP 

12  days 

Wed  12/lS/l(Thu  12/30/10 

33 

Document  Final  MOE  &  MOP  and  Metric  for 

12  days 

Wed 

Thu  12/30/10 

Measurements 

12/15/10 

34 

k* 

Verify  MOE  &  MOP  Support  Stakeholder  Meeds 

9  days 

Thu  12/30/10 

Tue  1/H/ll 

35 

Using  Top  Level  Architecture  (Functions),  Conduct  QFDs 

IS  days 

Tue  1/11/11 

Mon  1/31/11 

36 

k# 

Document  Alternatives  (Morphological  Matrix) 

15  days 

Tue  1/11/U 

Mon  1/91/11 

37 

k* 

Conduct  Scoring  to  identify  Top  Alternatives 

SS  days 

Tue  1/2S/11 

Mon  4/11/11 

38 

yv 

Conduct  Design  Trade-off  Analysis  and  Assessments 

16  days 

Tue  1/25/11 

Tue  2/15/11 

39 

yv 

Establish  Value  and  Worth  Scoring  for  Stakeholders 

6  days 

Thu  2/10/11 

Thu  2/17/11 

40 

W 

Define  Concept  Alternative  Risks  and  Feasibility 

11  days 

Tue  2/15/11 

Tue  3/1/H 

41 

V  + 

Establish  Life-Cycle  Cost  Estimates  for  Top  Alternatives 

22  days 

Sat  3/5/11 

Sat  4/2/11 

4  2 

J 

k* 

Model  and  Simulate  OPSITs  for  Alternatives 

36  days 

Mon  2/21/11 

Mon  4/11/11 

43 

W 

Determine  MOE  &  MOP  Measurements  for 

20  days 

Mon  2/21/11 

Fri  3/18/11 

Alternatives 

44 

k  * 

Perform  Modeling  of  Alternative  Functions 

11  days 

Mon  3/14/11 

Mon  3/28/11 

45 

yy 

Perform  LRS  Sensitivity  Analysis 

11  days 

Mon  3/28/11 

Mon  4/11/11 

46 

Is/'  y 

Conduct  Team  System  Functional  Review 

17  days 

Sun  3/20/11 

Sun  4/10/11 

47 

yy 

Conduct  Interim  Progress  Brief  #2  of  2  nd  QTR  Work 

1  day 

Mon  3/14/11 

Mon  3/14/11 

(Deliverable) 

48 

Y+ 

Conduct  Design  Synthesis  &  Verification 

36  days 

Mon  3/14/11 

Sat  4/30/11 

49 

Vy 

Conduct  Cost-Benefit  Analysis 

18  days 

Mon  3/14/11 

Wed  4/6/11 

SO 

Determine  CAIV 

18  days 

Mon  3/14/11 

Wed  4/6/11 

51 

ky 

Conduct  Interface  And  Design  Analysis 

36  days 

Mon  3/14/11 

Sat  4/30/11 

52 

y  y 

Develop  Test  Strategy 

15  days 

Mon  3/14/11 

Fri  4/1/11 

S3 

w 

Develop  Hardware/Software  Integration  Plan 

22  days 

Frl  4/1/11 

Sat  4/30/11 

54 

>y 

Assess  Safety  and  Usability 

30  days 

Tue  3/22/11 

Sat  4/30/11 

55 

y  y 

Assess  Logistics  Support 

22  days 

Frl  4/1/11 

Sat  4/30/11 

56 

yy 

Conduct  Reliability  Analysis 

7  days 

Sun  3/20/11 

Sun  3/27/11 

57 

V'y 

Propose  Final  Design  Recommendation 

14  days 

Wed  4/13/11 

Sat  4/30/11 

58 

✓y 

Validate  Final  Design  Recommendation  with  Stakeholder 

14  days 

Wed  4/13/11 

Sat  4/30/11 

J 

Requirements 

59 

yy 

Determine  Future  Exploration  Avenues 

22  days 

Fri  4/1/11 

Sat  4/30/11 

60 

jyy 

Project  Conclusion 

3Sdays 

Sat  4/30/11 

Wed  6/15/11 

61 

yy 

Complete  Draft  Final  Report 

23  days 

Sat  4/30/11 

Mon  5/30/11 

62 

ky 

Submit  to  S€  Department  Advisors  and  Secretary  for 

1  day 

Mon  5/16/11 

Mon  5/16/11 

Review  (Deliverable) 

63 

y  y 

Adjudicate  Comments  and  Submit  Final  Project  Report 

1  day 

Mon  5/30/11 

Mon  5/30/11 

(Deliverable) 

64 

ky 

Develop  Project  Presentation 

16  days 

Mon  5/16/11 

Mon  6/6/11 

August  September  October  November  December  January 
7/25  8/15  9/5  9/25  I  10/17  11/7  11/28  12/191  1/9 


February  March  April 
LllML  1  2/20  3/13  4/3, 


«  3/M 


Project:  UUV_Schedute_ll,04.19. 
Date:  Tue  4/19/11 


Task 

Spirt 

Milestone 

Summary 


Project  Summary 
1 1  h mu  1 1  m  i<  i mi  External  Tasks 
♦  External  Milestone 

Inactive  Task 


^  Inactive  Milestone 
Inactive  Summary 
Manual  Task 
Duration-only 


Manual  Summary  Rollup 
Manual  Summary  ^ 

■3  Start-only  C 

Finish-only  2 


mm  Deadline 
^F  Progress 


Page  2 


169 


ID 

iTask 

O  Mode 

Task  Name 

Duration 

Start 

Finish 

65 

V  + 

Deliver  Project  Presentation  for  Faculty  and 
Stakeholders  (Deliverable) 

1  day 

Mon  6/6/11 

Mon  6/6/11 

September  October  November  December  January 


7/25  8/15  9/5  9/26  10/17  11/7  11/28  12/19  1/9 


f 


February  March  April 
1/30  2/20  3/13  4/3 


Project:  UUV..Schedu*e_ll,04  19. 
Date:  Tue  4/19 fl\ 


Task 

Split 

Milestone 

Summary 


Project  Summary 
iHMMiiHMiMiM  External  T asks 
♦  External  Milestone 

Inactive  Task 


"9  Inactive  Milestone 
Inactive  Summary 
Manual  Task 
Duration-only 


Manual  Summary  Rollup  m 
Manual  Summary  ^ 

-3  Start-only  C 

Finish-only  3 


Deadline 

Progress 


Page  3 
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APPENDIX  B  -  CONCEPTUAL  ALTERNATIVE  GENERATION 


To  support  morphology  and  the  eventual  development  of  the  components  that  made  up  to  alternative  systems  examined  in  this 
report,  technologies  were  envisioned  for  each  component.  Either  these  technologies  could  be  known  fonns  that  perfonn  similar 
functions  necessary  per  QFD  requirements  or  they  could  be  ideas  or  concepts  which  may  or  may  not  come  to  fruition  with  research 
and  development. 

Using  literature  sources  and  experiences,  the  team  generated  at  least  two  technology  concepts  for  each  of  the  eight  (8)  major 
components.  Again,  using  judgment  and  experience,  these  technologies  were  ranked  in  the  areas  of  “Cost/Schedule”,  Technological 
Maturity”  and  “Expected  Performance”  to  assess  the  risks/impacts  on  a  final  concept  which  contained  the  technology.  Text  rankings 
were  initially  used;  however,  to  eventually  compare  and  contrast  the  technology  alternatives  for  a  given  component,  color  coding  of 
Green/Yellow/Red  where  used  with  Green  being  the  best.  This  is  because  a  technology  could  rank  “Low”  for  Cost/Schedule  and  be 
considered  beneficial,  but  also  rank  “Low”  for  Performance  and  be  considered  detrimental.  The  rankings  were  considered  with 
respect  to  the  other  potential  technologies  within  the  same  component  group.  For  instance,  a  Carbon  Steel  structure  is  considered 
lower  cost  compared  to  a  Titanium  structure,  which  the  actual  cost  in  terms  of  dollars  not  considered.  Whereas  the  actual  dollar  cost 
of  the  Carbon  Steel  structure  would  have  been  substantially  more  than  the  dollar  cost  of  an  Acoustic  Homing  Beacon. 

The  table  that  follows  contains  the  technologies  that  were  considered  for  each  component  package,  the  assessment  of  each 
technology  alternative  and  the  reasons  behind  the  rankings  received. 


171 


Table  1  -  Technology  Matrix 


Major 

Component 

Technology 

Cost/ 

Schedule 

Tech 

Maturity 

Perform 

Remarks 

Ranking  Reasoning 

Support 

Structure 

Carbon  Steel 

Low 

Mature 

Low 

Heavy,  corrosion, 
easy  to  work 

Carbon  steels  are  a  low  impact  to  cost/schedule  because  of  their  ample  availability 
and  established  trade  skill  set  in  working  with  these  materials.  They  are  a  mature 
technology  and  have  been  in  use  for  many  decades  in  submarine  applications.  Their 
performance  is  relatively  low  due  to  their  corrosive  nature  when  compared  with 
readily  available  alloys. 

Monel 

Medium 

Mature 

Medium 

Heavy,  dissimilar 
metal  weld  issues, 
costly 

Due  to  longer  lead  times  and  expense  in  procurement  of  monel  alloys,  they  are 
considered  a  medium  risk  to  cost/schedule.  However,  the  technological  maturity  is 
high  because  monel  alloys  have  been  used  in  submarine  construction  for  many 
decades.  Monel  performance  is  ranked  medium  because  it  is  preferred  to  carbon  steel 
due  to  better  corrosion  resistance  and  superior  strength  qualities. 

Aluminum 

Low 

Mature 

Low 

corrosion,  dissimilar 
metal  issues 

Aluminum  is  a  readily  available  material  so  the  cost  and  time  to  procure  it  is 
considered  low.  Aluminum  has  been  available  and  used  in  various  grades  for  decades 
so  the  technology  is  mature.  The  perfonnance  is  ranked  low  due  to  known  corrosion 
problems  in  seawater  applications  and  the  fact  that  welding  aluminum  to  dissimilar  is 
a  complex  process. 

Reinforced 

Carbon  Fiber 

High 

Mature 

Medium 

structural  strength 
issues,  non-reactive, 
difficult  to  repair 

Working  with  fiberglass  is  a  prolonged  process  and  the  manpower  required  for 
fiberglass  work  is  not  normally  found  in  shipbuilding  industry  so  cost/schedule  is 
considered  high.  Fiberglass  work  in  recreational  boating  and  automotive  industries 
has  been  around  for  decades  so  the  technology  is  considered  mature.  Performance  is 
considered  medium  because  of  the  non  reactive-to-seawater  property  of  it  but 
fiberglass  does  not  have  the  structural  strength  required  for  this  application  and  it  is 
difficult  and  time  consuming  to  repair.  i 

Ceramics 

High 

Conceptual 

High 

non-reactive, 
difficult  to  repair 

Ceramics  are  not  normally  used  by  the  marine  industry  and  especially  in  structural 
applications  so  the  cost  and  schedule  of  procuring  and  working  these  materials  is 
considered  high.  The  use  of  ceramics  has  been  around  for  centuries  in  pottery-like 
applications  but  the  use  of  newer  ceramic  materials  in  industrial  objects  is  still 
considered  conceptual.  Their  performance  is  considered  high  because  of  their 
resistance  to  corrosion  and  relative  light  weight.  However,  although  ceramics  are 
strong  in  compression,  they  are  weak  in  shearing  and  tension.  Additionally  they  are 
difficult  to  repair. 

Titanium 

High 

Mature 

High 

corrosion,  dissimilar 
metal  issues 

Titanium  is  a  readily  available  material  so  the  time  to  procure  it  is  considered  low  but 
at  a  high  cost.  Titanium  has  been  available  and  used  in  various  grades  for  decades  so 
the  technology  is  mature.  The  performance  is  ranked  high  due  to  advantages  in 
seawater  applications;  however,  the  fact  that  welding  titanium  to  dissimilar  is  a 
complex  process. 
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Major 

Component 

Technology 

Cost/ 

Schedule 

Tech 

Maturity 

Perform 

Remarks 

Ranking  Reasoning 

Divers 

Low 

Mature 

Low 

puts  humans  in 
danger,  slow 

Use  of  divers  has  virtually  no  impact  to  cost  or  schedule.  Navy  underwater  divers 
have  been  employed  in  salvage  and  recovery  operations  since  at  least  the  late  1 9th 
century  so  this  method  of  recovery  is  considered  mature.  Use  of  divers  is  considered 
a  low  performance  ranking.  It  is  not  the  preferred  method  of  recovery  due  to  the 
inherent  danger  associated  with  the  operation  and  time  required  to  deploy  and  retrieve 
the  divers 

Recovery 

Articulated 
Mechanical  Arm 

Medium 

Mature 

Medium 

slow,  complex  to 
operate,  tube  door 
open  for  extended 
period  (ship  safety) 

Construction  of  an  articulated  mechanical  arm  poses  the  possibility  of  high  cost  and 
schedule  impact  due  to  complexity.  The  technology  is  mature  in  normal  applications 
but  use  is  limited  in  underwater  applications  due  to  electro-mechanical  components. 

The  performance  is  medium  because  their  sluggish  operation  requires  that  outer  tube 
doors  remain  open  for  extended  periods. 

Mechanism 

ROV 

High 

Prototype 

High 

(deploy  homing 

ROVs  which  attach 
to  UUV  and  direct 
back  into  tube),  fast, 
more  items  to 
maintain 

ROVs  are  a  high  impact  to  cost  and  schedule  due  to  procurement  of  additional 
equipment  required  to  procure  and  design  storage  for  on  the  host  platform.  ROVs  for 
this  application  would  be  considered  a  prototype  meaning  that  the  technology  is  there 
to  build  them  but  it  has  yet  to  be  built  which  also  add  to  the  high  cost/schedule 
ranking.  Due  to  their  high  speed  in  retrieving  the  UUV,  they  are  considered  high  in 
performance. 

Electro¬ 
mechanical 
Attraction  Device 

High 

Prototype 

High 

fast,  high  power 
demand,  could 
damage  electronics, 
detectable  by  enemy 

Electro-mechanical  devices  are  basically  a  magnetic  apparatus  used  to  retrieve  a 

UUV.  Constructing  this  type  of  device  would  be  cost  prohibitive  because  of  the  power 
and  shielding  requirements.  This  device  is  considered  a  prototype  due  to  the  know¬ 
how  is  available  and  has  been  done  before,  but  not  for  this  application.  The  high  speed 
of  retrieving  a  UUV  warrants  a  high  performance  ranking. 

Launch  Ejection 
Gas  Generator 

Low 

Mature 

High 

Current  technology 
used  on  Strategic 
missiles  so  service 
proven 

Because  of  their  current  use  on  Trident  submarines,  cost  and  schedule  are  considered 
low.  Procurement  of  this  equipment  would  be  akin  to  an  off-the  shelf  purchase.  The 
technology  is  mature  and  has  been  in  proven  use  since  construction  of  Ohio  class.  The 
performance  is  high  because  of  the  speed  at  which  the  UUV  could  be  launched  and 
due  to  the  relative  low  maintenance  of  the  equipment.  Using  this  alternative  complies 
with  commonality  policy 

Launch 

Mechanism 

Release  a  catch 
(UUV  "swims" 
away 

on  its  own) 

Low 

Mature 

Medium 

susceptible  to  ocean 
currents  during 
launch 

Release  a  catch  allows  a  UUV  to  swim  out  of  the  tube  under  its  own  power.  This  is 
considered  a  low  impact  to  cost/schedule  since  no  additional  equipment  is  required 
and  a  mature  technology  since  existing  UUV  are  currently  operating  on  their  own 
power.  Potential  issue  with  accidental  contact  with  sub  on  recovery. 

Articulated 
Mechanical  Arm 

Medium 

Mature 

Medium 

slow,  complex  to 
operate,  tube  door 
open  for  extended 
period  (ship  safety) 

Construction  of  an  articulated  mechanical  arm  poses  the  possibility  of  high  cost  and 
schedule  impact  due  to  complexity.  The  technology  is  mature  in  normal  applications 
but  use  is  limited  in  underwater  applications  due  to  electro-mechanical  components. 

The  performance  is  medium  because  their  sluggish  operation  requires  that  outer  tube 
doors  remain  open  for  extended  periods. 

173 


Major 

Component 

Technology 

Cost/ 

Schedule 

Tech 

Maturity 

Perform 

Remarks 

Ranking  Reasoning 

Divers 

Low 

Mature 

Low 

puts  humans  in 
danger,  slow 

Use  of  divers  has  virtually  no  impact  to  cost  or  schedule.  Navy  underwater  divers 
have  been  employed  in  salvage  and  recovery  operations  since  at  least  the  late  1 9th 
century  so  this  method  of  recovery  is  considered  mature.  Use  of  divers  is  considered 
a  low  performance  ranking.  It  is  not  the  preferred  method  of  recovery  due  to  the 
inherent  danger  associated  with  the  operation  and  time  required  to  deploy  and  retrieve 
the  divers 

ROV 

High 

Prototype 

High 

(deploy  homing 

ROVs  which  attach 
to  UUV  and  direct 
back  into  tube),  fast, 
more 

items  to  maintain 

ROVs  are  a  high  impact  to  cost  and  schedule  due  to  procurement  of  additional 
equipment  required  to  procure  and  design  storage  for  on  the  host  platform.  ROVs  for 
this  application  would  be  considered  a  prototype  meaning  that  the  technology  is  there 
to  build  them  but  it  has  yet  to  be  built  which  also  add  to  the  high  cost/schedule 
ranking.  Due  to  their  high  speed  in  retrieving  the  UUV,  they  are  considered  high  in 
performance. 

Electro¬ 
mechanical 
Repulsion  Device 

High 

Prototype 

High 

fast,  high  power 
demand,  could 
damage  electronics, 
detectable  by  enemy 

Electro-mechanical  devices  are  basically  a  magnetic  apparatus  used  to  retrieve/repulse 
a  UUV.  Constructing  this  type  of  device  would  be  cost  prohibitive  because  of  the 
power  and  shielding  requirements.  This  device  is  considered  a  prototype  based  on  the 
know-how  is  available  and  has  been  done  before,  but  not  for  this  application.  The 
relative  high  speed  of  repulsing  a  UUV  warrants  a  high  performance  ranking. 

UUV  Power 
and 

Re-Charging 

Mechanism 

Batteries 
recharged 
on  Host  Sub 
(replaced  on  UUV 
while  launched, 
by 

ROV  or  divers) 

Low 

Mature 

Low 

Divers  would  need 
to  rendezvous  with 
UUV  and  recharge  it 

Removal  and  replacement  of  existing  batteries  had  no  cost  or  schedule  risk.  The 
existing  UUV  batteries  would  be  mature,  and  provide  high  performance.  However, 
the  issues  involve  with  diver  replacement  are  similar  to  that  described  for  use  in 
recovery. 

Undersea 

Recharging 

Docking  Station 

Medium 

Prototype 

Medium 

Smaller  Scale  station 
used  for 

REMUS 

This  was  ranked  medium  on  cost/schedule  and  performance,  since  the  REMUS 
docking  station  could  be  considered  a  prototype.  The  ability  to  use  it  for  a  larger 
vehicle  and  different  battery  is  what  made  it  medium. 

Pulse  Charge 
(while  UUV 
launched) 

High 

Conceptual 

Low 

feasibility  of  doing 
this  under  sea  from 
submarine  not 
defined 

High  cost  and  performance  issues  equate  to  the  pulse  charge  since  it  is  conceptual. 
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Major 

Component 

Technology 

Cost/ 

Schedule 

Tech 

Maturity 

Perform 

Remarks 

Ranking  Reasoning 

Charging  pad 
(while  UUV 
stowed) 

High 

Conceptual 

High 

based  on  electric  car 
battery  recharging 
system 

Technology  has  not  been  demonstrated  for  cars.  Undersea  wireless  communications 
issues  have  fidelity  issues  (thus  the  high  cost  and  schedule  risk).  However,  if 
successful,  could  support  inductive  charging  at  a  distance  and  in  wet  environments. 

Host  sub 
releases  charging 
cable  (while 

UUV  launched) 

Low 

Mature 

Medium 

cable  would  be 
prone  to  flooding 

Cost  of  cabling  is  low;  technology  is  mature  with  external  cables  in  use  in  several 
submarine  systems;  performance  is  medium  because  external  cables  are  prone  to 
flooding  leaving  them  damaged.  Dry  charge  would  require  a  dry  compartment,  but 
would  improve  performance. 

Stowage 

System 

Catch/lock/clasp 
in  payload  tube 

Medium 

Mature 

Medium 

simple,  potential  for 
binding 

Cost  is  medium  due  to  additional  hardware  and  heavy  duty  moving  parts  required; 
technology  is  medium;  Performance  is  medium  because  this  system  will  require  the 
UUV  to  launch  and  recover  under  its  own  power. 

Canister  that 

retracts 

into  payload  tube 

High 

Conceptual 

Medium 

would  be  part  of  the 

launch/recovery 

system 

Cost  is  high  due  to  additional  hardware  and  complex  precision  heavy  duty  moving 
parts  required;  Conceptual  technology  in  underwater  applications;  Performance  is 
medium  based  on  relative  sluggish  operation  of  moving  . 

Magnet  in 
payload  tube 

High 

Prototype 

High 

large  magnets  would 
be  costly 

Cost  is  high  based  on  large  size  of  magnet  required  to  retain  a  large  UUV; 

Technology  for  magnets  is  mature  (even  large  sizes)  but  are  not  in  use  for  this  system 
so  prototype  technology;  performance  is  high  because  of  low  number  of  moving  parts 
and  clean  installation. 

Sealed 

compartments 
in  payload  tube 

Medium 

Mature 

High 

each  UUV  would 
have  designated 
stowage  spaces 

Cost  is  medium  base  on  additional  structural  work  required  to  create  sealed 
compartments  in  the  tube;  Current  shipbuilding  practices  could  accommodate  building 
of  separate  compartments;  Performance  is  high  because  each  UUV  will  have  its  own 
designated  stowage  area. 

Control 

System 

Architecture 

Portable  plug-in 
control  system 

Low 

Mature 

Medium 

A  carry-on 
technology,  not 
stored  on  board 
when  subs  mission 
doesn't  require  UUV 
operations 

Cost  is  low  because  no  additional  space  has  to  be  designed  into  submarine  to 
accommodate  control  system  hardware;  "Carry-On"  hardware  is  currently  employed 
on  submarines  so  technology  is  mature;  Performance  is  medium  based  on  system  not 
being  fully  integrated  with  sub  and  taking  up  space  normally  used  by  other 
equipment.  Laptop  would  be  designed  to  fit  in  19  inch  ranks 
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Major 

Component 

Technology 

Cost/ 

Schedule 

Tech 

Maturity 

Perform 

Remarks 

Ranking  Reasoning 

Hardwired 
integrated  system 

Medium 

Mature 

Low 

System  becomes 
permanently  part  of 
the 

submarine's  on¬ 
board  systems 

Cost  of  installing  additional  hardware/software  into  sub  to  accommodate  control 
system  is  medium;  Most  systems  on  a  sub  are  hardwired  system  so  technology  is  very 
mature;  Performance  of  a  hardwired  system  is  low  because  additional  submarine 
space  has  to  be  found  to  accommodate  control  system  hardware  and  potential 
interface  performance  issues. 

Wireless 

integrated 

system 

Medium 

Prototype 

High 

System  becomes 
permanently  part 
of  the  submarine's 
on-board  systems 

Cost  of  wireless  is  medium  due  to  no  cabling  being  required  but  still  need  space  for 
hardware;  Wireless  technology  is  mature  but  few  or  no  systems  exist  for  this 
application  so  technology  is  prototype;  Performance  is  high  as  there  are  no  additional 
cables  penetrating  the  hull  which  would  be  prone  to  cable  flooding  issues. 

Communi- 
cations 
(docked  or 
undocked), 
both  RF  and 
Acoustic  to 
be 

considered 

Radio  frequency 

Low 

Prototype 

High 

Radio  signal 
propagation  is 
dependent  on 
temperature,  salinity, 
and  depth.  Usually 
difficult  to  transmit 
effectively 
underwater. 

Cost  of  RF  is  medium  due  to  no  cabling  being  required  but  still  need  space  for 
hardware;  RF  technology  is  mature  but  few  or  no  systems  exist  for  this  application  so 
technology  is  prototype;  Performance  is  high  as  there  are  no  additional  cable 
penetrating  the  hull  which  would  be  prone  to  cable  flooding  issues. 

Hard-wired 

Medium 

Mature 

Low 

System  becomes 
permanently  part  of 
the  submarine's  on¬ 
board  systems 

Cost  of  installing  additional  hardware/storage  into  sub  to  accommodate  excess  cabling 
is  medium;  hardwired  technology  is  very  mature;  Performance  of  a  hardwired  system 
is  low  because  additional  submarine  space  has  to  be  found  to  accommodate  cabling 
plus  it’s  impractical  to  the  mission. 

Acoustic 

Medium 

Prototype 

High 

System  becomes 
permanently  part  of 
the  submarine's  on¬ 
board  systems. 

Subject  to  multi -path 
propagation,  time 
variations  of  the 
channel  and  limited 
available  bandwidth 

Cost  of  acoustic  system  is  medium  due  to  no  cabling  being  required  but  still  need 
space  for  hardware;  Acoustic  technology  is  mature  but  few  or  no  systems  exist  for  this 
application  so  technology  is  prototype;  Performance  is  high  as  there  are  no  additional 
cables  penetrating  the  hull  which  would  be  prone  to  cable  flooding  issues. 
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APPENDIX  C  -  COST  ANALYSIS  WORKSHEETS 


Acquisition  cost  considerations  for  conceptual  alternatives  were  established  by  using  cost  data 
or  similar  equipment.  The  tables  established  below  provide  the  information  the  team  used  to  arrive  at 


from  internet  and 
the  cost  estimates 


peer  sources  for  exact 
for  each  alternative. 


Overall  Worksheet 


Cost:  Category 

s 

Engineeringand 

Design 

General  And 

Administrative 

Manufacturing/Ins 

tallation 

Program 

Management 

Disposal 

Material 

Spare  Parts 

_ 

Mhr  Rate 

$  85 

$  50 

$  80 

$  85 

$  80 

$  85 

N/A 

N/A 

Support  Structure 

Option  A:  Carbon  Steel 

Man  hours 

200 

1,500 

375 

2,000 

200 

350 

4,625 

Cost 

$  17,000 

$  75,000 

$  30,000 

$  170,000 

$  16,000 

$  29,750 

$  1,200,000 

$  75,000 

’  $  1,612,750 

Option  B:  Fibergless 

Man  hours 

200 

1,  500 

375 

2,000 

200 

350 

4,625 

Cost 

$  17,000 

$  75,000 

$  30,000 

$  170,000 

$  16,000 

$  29,750 

$  12,040,000 

$  200,  OOO 

'  $  12,577,750 

Option  O:  Titanium 

Man  hours 

250 

1, 500 

375 

2,000 

200 

350 

4,675 

Cost 

$  21,250 

$  75,000 

$  30,000 

$  170,000 

$  16,000 

$  29,750 

$  5,400,000 

$  150,000 

$  5,892,000 

Recovery  Mechanism 

Option  A:  Articulated  Mechanical  Arm 

Man  hours 

50 

200 

50 

2,000 

200 

200 

2, 700 

Cost 

$  4,250 

$  10,000 

'  $  4,000 

$  170,000 

$  16,000 

$  17,000 

$  239,000 

$  2,000 

'  $  462,250 

Option  B:  Remote  Vehicle  (ROV) 

Man  hours 

50 

200 

50 

2,000 

200 

200 

2, 700 

Cost 

$  4, 250 

$  10,000 

$  4, 000 

$  170,000 

$  16,000 

$  17,000 

$  165,000 

$  1, 600 

"  $  204, 250 

Option  O:  Electro-mechanical  Attraction  Device 

Man  hours 

15 

150 

37.5 

1,200 

120 

200 

1,723 

Cost 

$  1,275 

$  7,500 

$  3,000 

$  102,000 

$  9,600 

$  17,000 

$  27,000 

$  1,000 

$  123,375 

Lau nch  Mechanism 

Option  A:  Launch  Ejection  Gas  Generator 

Man  hours 

150 

200 

50 

2,000 

200 

300 

2,900 

Cost 

$  12,750 

$  10,000 

$  4,  OOO 

$  170,000 

$  16,000 

$  25,500 

$  347,000 

$  75,000 

'  $  660,250 

Option  B:  Release  a  catch 

Man  hours 

20 

lOO 

25 

200 

50 

50 

445 

Cost 

$  1,700 

$  5,000 

$  2,000 

$  17,000 

$  4,000 

$  4,250 

$ 

$ 

r  $  33,950 

Option  O:  Electro-mechanical  Repulsion  Device 

Man  hours 

15 

150 

37.5 

1,200 

120 

200 

1,723 

Cost 

$  1,275 

$  7,500 

$  3,000 

$  102,000 

$  9,600 

$  17,000 

$  27,000 

$  5,000 

$  172,375 

Rower  and  Recharging  Mechanism 

Option  1 :  Physical  cable  connection 

Man  hours 

5 

IO 

2.5 

80 

20 

40 

158 

Cost 

$  425 

$  500 

$  200 

$  6, 800 

$  1, 600 

$  3,400 

$  4, 500 

$  1,000 

$  18,425 

Option  2:  Hostsub  releases  charging  cable 

Man  hours 

5 

IO 

2.5 

80 

20 

40 

158 

Cost 

$  425 

$  500 

$  200 

$  6, 800 

$  1, 600 

$  3,400 

$  6, 550 

$  1,000 

$  20,475 

Option  3:  Induction  charging  pad  device 

Man  hours 

5 

20 

5 

80 

20 

40 

170 

Cost 

$  425 

$  1,000 

$  400 

$  6, 800 

$  1, 600 

$  3,400 

$  11,050 

$  2, 500 

$  13,625 

Stowage  Syste  m 

Option  1 :  Catch/lock/clasp  in  payload  tube 

Man  hours 

io 

80 

20 

200 

50 

50 

410 

Cost 

$  850 

$  4,000 

$  1, 600 

$  17,000 

$  4,000 

$  4,250 

$  38,500 

$  4, 500 

$  74, 700 

Option  2:  Magnet  in  payload  tube 

Man  hours 

IO 

80 

20 

200 

50 

50 

410 

Cost 

$  850 

$  4,000 

$  1, 600 

$  17,000 

$  4,000 

$  4,250 

$  3,  lOO 

$  1, 500 

$  36,300 

Option  3:  Sealed  compartments  in  payload  tube 

Man  hours 

20 

80 

20 

200 

50 

50 

420 

Cost 

$  1,700 

$  4,000 

$  1,600 

$  17,000 

$  4,000 

$  4,250 

$  55,000 

$  3, 500 

$  32,550 

Control  System 

Option  1 :  Portable  plug-in  control  system 

Man  hours 

5 

IO 

2.5 

80 

20 

40 

158 

Cost 

$  425 

$  500 

$  200 

$  6, 800 

$  1, 600 

$  3,400 

$  11,430 

$  1, 500 

"  $  25,855 

Option  2:  Hardwired  integrated  system 

Man  hours 

5 

IO 

2.5 

80 

20 

40 

158 

Cost 

$  425 

$  500 

$  200 

$  6, 800 

$  1, 600 

$  3,400 

$  11,550 

$  1, 500 

$  24,475 

Radio  Communication 

Radio  frequency 

Man  hours 

5 

30 

7.5 

80 

20 

40 

183 

Cost 

$  425 

$  1, 500 

$  600 

$  6, 800 

$  1, 600 

$  3,400 

$  7,500  |  $  1,500 

$  14, 325 

Acoustic  Communication 

Acoustic 

Man  hours 

5 

40 

IO 

80 

20 

40 

195 

Cost 

$  425 

$  2,000 

$  800 

$  6, 800 

$  1, 600 

$  3,400 

$  19, 180 

$  1, 500 

$  15,025 

Other  Assumptions 

1.  For  Manufacturing  and  Installation  a  man  hour  rate  of  $85/hr  is  assumed 

2.  For  Engineering  and  Design  a  man  hour  rate  of  $50/hr  is  assumed 

2.  For  General  and  Administrative  a  man  hour  rate  of  $>80/ h r  is  assumed 

3.  For  every  4  hours  of  M  &  1,  there  is  1  hour  of  G  &  A 
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POWER  AND  RECHARGING 

Option  1:  Physical  cable  connection 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Cable 

$1,400 

Similar  VLS  cabling/connectors 

$1,400 

$8,400 

2 

1 

External  Connector 

$950 

Similar  VLS  cabling/connectors 

$950 

$5,700 

1 

Additional  inboard 
cabling 

$2,000 

estimate 

$2,000 

$12,000 

3 

1 

Internal  Connector 

$200 

Similar  VLS  cabling/connectors 

$200 

$1,200 

Total: 

$4,550 

$27,300 

Option  2:  Hostsub  releases  charging  cable 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Cable 

$1,400 

Similar  VLS  cabling/connectors 

$1,400 

$8,400 

2 

1 

External  Connector 

$950 

Similar  VLS  cabling/connectors 

$950 

$5,700 

1 

Additional  inboard 
cabling 

$2,000 

estimate 

$2,000 

$12,000 

1 

Internal  Connector 

$200 

Similar  VLS  cabling/connectors 

$200 

$1,200 

3 

1 

Cable  release  mech 

$2,000 

estimate 

$2,000 

$12,000 

Total: 

$6,550 

$39,300 

Option  3:  Induction  charging  pad  device 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Cable 

$1,400 

Similar  VLS  cabling/connectors 

$1,400 

$8,400 

2 

1 

External  Connector 

$950 

Similar  VLS  cabling/connectors 

$950 

$5,700 

1 

Additional  inboard 
cabling 

$2,000 

estimate 

$2,000 

$12,000 

1 

Internal  Connector 

$200 

Similar  VLS  cabling/connectors 

$200 

$1,200 

3 

1 

Charging  Pad 

$6,500 

estimate 

$6,500 

$39,000 

Total: 

$11,050 

$66,300 
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LAUNCH  MECHANISM 

Option  1:  Launch  Ejection  Gas  Generator 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Gas  Generator 

$250,000 

estimate 

$250,000 

$1,500,000 

2 

1 

Associated  Piping 

$75,000 

estimate 

$75,000 

$450,000 

3 

1 

Control  System 

$22,000 

estimate 

$22,000 

$132,000 

Total: 

$347,000 

$2,082,000 

Option  2:  Release  a  Catch 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

$0 

2 

1 

$0 

3 

1 

$0 

Total: 

$0 

$0 

Option  3:  Electro  Mechanical  Repulsion  Device 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

motor-generator 

$20,000 

similar  shipboard  models 

$20,000 

$120,000 

2 

1 

cables/wire/coil 

$4,000 

estimate 

$4,000 

$24,000 

3 

1 

core  material 

$3,000 

estimate 

$3,000 

$18,000 

Total: 

$27,000 

$162,000 
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RECOVERY  MECHANISM 

Option  1:  Articulated  Mechanical  Arm 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Articulating  Arm 

$225,000 

estimate 

$225,000 

$1,350,000 

2 

1 

Software 

$4,000 

estimate 

$4,000 

$24,000 

3 

1 

Control  System 

$10,000 

estimate 

$10,000 

$60,000 

Total: 

$239,000 

$1,434,000 

Option  2:  Remote  Vehicle  (ROV) 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

ROV 

$125,000 

price  scaled  based  on  smaller 
ROVs 

$125,000 

$750,000 

2 

1 

ROV  Control  System 

$15,000 

estimate 

$15,000 

$90,000 

3 

1 

ROV  Storage 

$25,000 

estimate 

$25,000 

$150,000 

Total: 

$165,000 

$990,000 

Notes:  1.  smaller  ROVs  price  around  $15,000-  $20,000 

Option  3:  Electro-mechanical  Attraction  Device 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

motor-generator 

$20,000 

similar  shipboard  models 

$20,000 

$120,000 

2 

1 

cables/wire/coil 

$4,000 

estimate 

$4,000 

$24,000 

3 

1 

core  material 

$3,000 

estimate 

$3,000 

$18,000 

Total: 

$27,000 

$162,000 

Notes: 

1.  If  ship's  diesel  generator  is  used  to  provide  current  to  the  coil,  a  separate  generator  is  unnessary. 
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CONTROL  SYSTEM 

Option  1:  Portable  plug-in  control  system 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR  ONE 

SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Cable  to  TR 

$1,400 

Current  VLS  weapon  control  cable 

$1,400 

$8,400 

2 

Pigtail  to  laptop 

$600 

estimate 

3 

1 

External  Connector 

$950 

Current  VLS  outboard  30-pin  connector 

$950 

$5,700 

4 

1 

Internal  Connector 

$200 

Current  VLS  inboard  connector 

$200 

$1,200 

5 

1 

Carry-on  Laptop 

$3,880 

Getac  V200  rugged  tablet  PC 
http://ruggednotebooks .  com/getac-v200- 
fully-rugge  d-c  onvertible  -tablet-laptop 

$3,880 

$23,280 

6 

1 

Software 

$5,000 

high-end  custom  software  similar  costs 

$5,000 

$5,000 

Total: 

$11,430 

$43,580 

Note: 

Total  software  cost  based  extending  software  license  to  six  systems 

Option  2:  Hardwired  control  system 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR  ONE 

SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Cable 

$1,400 

Current  VLS  weapon  control  cable 

$1,400 

$8,400 

2 

1 

External  Connector 

$950 

Current  VLS  outboard  30-pin  connector 

$950 

$5,700 

3 

1 

Additional  inboard  cabling 

$2,000 

estimate 

4 

1 

Internal  Connector 

$200 

Current  VLS  inboard  connector 

$200 

$1,200 

5 

1 

Computer 

$4,000 

estimate 

$4,000 

$24,000 

6 

1 

Software 

$5,000 

high-end  custom  software  similar  costs 

$5,000 

$5,000 

Total: 

$11,550 

$44,300 

Notes: 

1.  Total  software  cost  based  extending  software  license  to  six  systems 

2.  Computer  will  be  installed  in  existing  fire  control  console  in  Control  resulting  in  a  dual  purpose  station 

3.  Additional  inboard  cabling  will  be  from  hull  penetration  to  Control 
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SUPPORT  STRUCTURE 

Options  1,  2  &  3: 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Carbon  Steel  Support  Structure 

$1,200,000 

carbon  steel  price  expressed  as 
cost  of  qty.  (1)  MAC  structure 

$1,200,000 

$7,200,000 

2 

1 

Titanium  Support  Structure 

$12,040,000 

titanium  price  expressed  as  a 
percentage  of  qty.  (1)  MAC  structure 

$12,040,000 

$72,240,000 

3 

1 

Carbon  Fiber  Support  Structure 

$5,400,000 

Carbon  Fiber  price  expressed  as  a 
percentage  of  qty.  (1)  MAC  structure 

$5,400,000 

$32,400,000 

Total: 

Notes: 

1.  Based  on  current  cost  of  SSGN/SSN  Multiple  All-Up  Cannisters  (sourced  through  Electric  Boat) 

2.  carbon  steel  price  estimated  using  current  $US/ton  (http://www.meps.co.uk/world-price.htm)  ($0. 40/lb  or  $815/ton) 

3.  titanium  prices  obtained  from  http://www.metalprices.com/freesite/metals/ti_product/ti_product.asp  (approx  $7. 00/lb  or  $22, 300/ton) 

4.  carbon  fiber  price  obtained  from  http://www.compositesworld.com/news/doe-advances-lower-cost-carbon-fiber-rampd  ($8/1  b  or  $16, 000/ton) 

5.  $2,000,000  MAC  price  obtained  from  EB  (Cathy  Innes) 

6.  MAC  materials  consist  of  various  steels  (HY,  stainless,  etc) 

Material 

Density  (g/cm3) 

Density  ( 1  b/f  t3) 

$/lb 

$/system 

Pounds 

Volume 

Carbon  Steels 

7.85  g/cm3 

490 

$  0.40 

$  1,200,000 

3000000 

6122.449 

Titanium 

4.506  g/cm3 

281 

$  7.00 

$  12,042,857 

1720408 

6122.449 

Carbon  Fibers 

1.78  g/cm3 

111 

$  8.00 

$  5,436,735 

679592 

6122.449 
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STOWAGE  MECHANISM 

Option  1:  Catch/lock/clasp  in  payload  tube 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

additional  hydraulic 
piping 

$2,500 

estimate 

$2,500 

$15,000 

2 

1 

hydraulic  actuator 

$6,000 

based  on  VLS  fairing 
locking  cylinder 

$6,000 

$36,000 

3 

1 

locking  mechanism 

$30,000 

based  on  VLS  fairing 
locking  mechanism 

$30,000 

$180,000 

Total: 

$38,500 

$231,000 

Notes: 

1.  Used  APLfor  locking  cylinder  and  locking  mechanism  to  obtain  actual  costs 

Option  2:  Magnet  in  payload  tube 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Samarium  Cobalt 
Magnet  (2"x26") 

$1,100 

$/lb  of  a  SmCo  magnet 

$1,100 

$6,600 

2 

1 

Installation  hardware 

$2,000 

estimate 

$2,000 

$12,000 

Total: 

$3,100 

$18,600 

Notes: 

1.  According  to  http://www.magnetshop.com/materials.html,  Samarium  Cobalt  (SmCo)  is  a  suitable 
magnet  material  for  advanced  technical  applications. 

2.  SmCo  cost  is  approx  $70/1  b 

3.  Density  of  SmCo  0.3  1  bs/i  n3 

4.  Assume  a  2"  thk  x  26"  dia  (arbitrary  diameter  chosen)  =  52  in3  =  15.6  lbs  =  $1,100 

Option  3:  Sealed  compartments  in  payload  tube 

ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

additional  structure  to 

accommodate  seals 

$35,000 

estimate 

$35,000 

$210,000 

2 

1 

sealing  hatches 

$20,000 

estimate 

$20,000 

$120,000 

Total: 

$55,000 

$330,000 
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RADIO  COMMUNICATION 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

transmitter/ amplifier 

$5,000 

estimate 

$5,000 

$30,000 

2 

1 

receiver 

$2,500 

estimate 

$2,500 

$15,000 

Total: 

$7,500 

$45,000 

Notes:  1.  Assumed  a  basic  radio  system  that  could  be  used  to  send  a  signal  to  the  LRS  from  inside  the  host  sub 


ACOUSTIC  COMMUNICATION 


ITEM 

QTY. 

DESCRIPTION 

COST 

ESTIMATE 

BASED  ON 

TOTAL  FOR 

ONE  SYSTEM 

TOTAL  FOR 

SIX  SYSTEMS 

1 

1 

Laptop  with 
preinstalled  HAIL 
(Hydro  Acoustic 
Information  Link) 
software  &  modem 

3880  + 
$15,000 

Getac  V200  rugged  tablet  PC 
http://ruggednotebooks.com/ge 
tac-v200-fully-rugged- 
c  onvertible  -tablet-laptop 

$18,880 

$113,280 

2 

1 

power  supply 

$300 

estimate 

$300 

$1,800 

Total: 

$19,180 

$115,080 

Notes:  1.  Based  estimates  on  of  L3  HAILsystem  (http://www.l-3com.com/nautronix/products/pdf/NMS-C-SS- 


002HydroAcousticlnformationLinkSpecificationSheetR2.pdf) 
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APPENDEX  D  -  FUNCTIONAL  MODELING 


A.  LAUNCH  MODEL 


Fair*? 


Moderate 


Poor  - 


=6uccess  Fair 
Failure  Fair 


^Std  Detfauncfc 


Lai*ich  Success 


Success_Fair 
Success_Mod 
Success  Poor 


uccess  Mod 
ailure  Mod 


Launch  Success 


Failure  Fair 
Failure  Mod  ■ 
Failure_Poor 


niooth  Launch 


mplicated_Launch 


c=Success_Poor 

=Failure_Poor 


DB:opsct1:OPSn*1  -> 

Excel  Usouthem'ijptojeky.Desktop'.jlqjek  work ng f dde^Capstone'' Model  Rev\test123.xlsx 


Launch  Success 


smooth  Launch. 


=JtotDetected,noHostDamage_S 
=--notDetected,HostDamage_S 
-Detected, noHostDamage_S 
-  — Detected, hostDamage_S 


notDetected.noHostDamaae  S 
notDetected,noHostDamage_F 

notDetected,HostDamage_S 

notDetected,HostDamage_F 


lotDetected.NoHostDamage 

lotDetected.HostDamage 


Detected  ,noHostDamage_S 
Detected,noHostDamage_F 


tected.noHostDamage 


complicated_Launch  - 


notDetected.NoHostDamage 
notDetected. HostDamage 
Detected  .noHostDamage 
Detected, HostDamage 

LRS 


^notDetected.noHostDamaae  F 
r^^notDetected. HostDamage  F 
=^=Oetected  ,noHostDamage_F 
^&--Detected,hostDamage_F 


Detected.hostDamaqe  S 
Detected  ,hostDamage_F 


sDetected.HostDamage 


Launch  Time  • 


The  launch  model  simulated  1000  LRS  launches  for  each  alternative  and  its  results  are  provided  in  Table 
A  (in  this  Appendix).  Each  launch  was  independent  of  the  previous  launch  and  independent  of  the  three 
remaining  system  functions:  Recovery,  Maintain  and  Replenish.  Launch  condition  were  described  as  Fair, 
Moderate  or  Poor,  and  each  expressed  with  a  constant  likelihood.  Launch  condition  parameters  were  not 
variable  and  remained  fixed  for  all  launch  simulations.  The  modeling  parameters  identified  in  Table  19  of 
the  report  were  used  for  Launch  Modeling.  The  likelihood  of  a  Smooth  or  Complicated  Launch  was 
dependent  on  the  launch  condition  of  Fair,  Moderate  or  Poor.  The  likelihood  of  success  is  more  probable 
during  a  smooth  launch  than  a  complicated  launch  and  was  defined  as  Not  Detected  and  No  Damage.  The 
parameters  used  for  defining  the  likelihoods  leading  to  success  are  described  in  Table  A.  All  simulations 
results  were  outputted  to  a  Microsoft  Excel  spreadsheet  where  a  descriptive  analysis  was  perfonned  to 
evaluate  the  perfonnance  of  the  launch  function. 
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Table  A  -  Launch  Model  Raw  Data 


Launch  Model  Raw  Data 


Not  Detected  & 
No  Host  Damage 

Not 

Detected 
&  Host 
Damaged 

uuv 

Detected  & 
No  Host 
Damage 

UUV 

Detected  & 
Host 
Damaged 

LRS 

Success 

Launch 

Time 

[min] 

Alt-1 

90.3% 

2.5% 

1.8% 

3.8% 

98.4 

% 

11.25 

Alt-2 

85.4% 

2.5% 

2.5% 

6.8% 

97.2 

% 

11.25 

Alt-3 

89.4% 

4.0% 

0.6% 

5.2% 

99.2 

% 

11.33 

Alt-4 

90.1% 

2.1% 

1.1% 

4.7% 

98.0 

% 

12.84 

Baselin 

e 

81.5% 

3.4% 

3.2% 

8.9% 

97.0 

% 

14.97 
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Table  B  -  Launch/Recovery  Likelihoods  in  Varying  Conditions 


Baseline 

Alt  1 

Alt  2 

Alt  3 

Alt  4 

Smooth  Launch  in  Fair  Condition 

93.00 

% 

97.00 

% 

95.00 

% 

96.00 

% 

97.00 

% 

Smooth  Launch  in  Moderate  Condition 

90.00 

% 

94.00 

% 

92.00 

% 

93.00 

% 

94.00 

% 

Smooth  Launch  in  Poor  Condition 

80.00 

% 

84.00 

% 

82.00 

% 

83.00 

% 

84.00 

% 

Smooth  Launch:  No  Damage  &  Not  Detected 

92.00 

% 

96.00 

% 

94.00 

% 

95.00 

% 

96.00 

% 

Smooth  Launch:  No  Damage  &  Detected 

3.50% 

2.00% 

3.50% 

3.50% 

3.00% 

Smooth  Launch:  Damaged  &  Not  Detected 

3.00% 

1.50% 

1.50% 

1.00% 

0.75% 

Smooth  Launch:  Damaged  &  Detected 

1.50% 

0.50% 

1.00% 

0.50% 

0.25% 

Complicated  Launch:  No  Damage  &  Not 
Detected 

1.50% 

0.50% 

1.00% 

0.50% 

0.25% 

Complicated  Launch:  No  Damage  &  Detected 

3.00% 

1.50% 

1.50% 

1.00% 

0.75% 

Complicated  Launch:  Damaged  &  Not 

Detected 

3.50% 

2.00% 

3.50% 

3.50% 

3.00% 

Complicated  Launch:  Damaged  &  Detected 

92.00 

% 

96.00 

% 

94.00 

% 

95.00 

% 

96.00 

% 

Expected  Likelihood  of  Successful  Launch 
(No  Damage  &  Not  Detected) 

86.07 

% 

92.69 

% 

89.35 

% 

90.77 

% 

92.45 

% 
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B.  RECOVERY  MODEL 


Poor  = 


=Success_Poor 
^Failure  Poor 


Recovery  Success 


notDetected.noHostDamaae  S  = 
notDetected, no  HostDam  age_F= 


lotDetected.NoHostDamage 


smooth_Recovery>= 


iftotDetected,noHostDamage_S 
-  -notDetected.HostDamage_S 
^Detected  ,noHostDamage_S 
--  -=Oetected,hostDamage_S 


notDetected,HostDamage_S 

notDetected,HostDamage_F 


otDetected.HostDamage 


Detected.noHostDamaoe  S 
Detected  ,noHostDamage_F 


letected.noHos  (Damage 


complicated_Recovery = 


notDetected.NoHostDamage 
notDetected.HostDamaqe 
Detected.noHostDamage 
Detected.HostDamage 
Failed  Comm  ■= 
LRS  Failure  ■ - - 


otDetected,noHostDamage_F 
-rotDetected  ,HostDamage_F 
=Oetected,noHostDamage_F 
detected  ,hostDamage_F 
DB 


Detected  .hostDamaoe  S* 
Detected, hostDam  age_F = 


Detected  .HostDam  age 


Recovery  Time  - 


The  Recovery  Model  is  nearly  identical  to  that  used  to  evaluate  the  performance  of  launching  utilizing  the 
parameters  identified  per 
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Table  19  of  the  report  and  Table  B  and  simulated  1000  recoveries.  Raw  data  of  each  alternative  model  is 
provided  in  Table  C.  A  new  variable  was  added  to  model  the  likelihood  of  communication  linkage  of  the 
host  platfonn  and  returning  UUV  for  retrieval.  Failed  communication  link  would  ultimately  result  in  a 
failed  attempt  to  recovery  the  UUV.  If  communications  is  successful  the  same  order  of  events  and 
likelihoods  described  in  the  launch  procedure  are  followed.  Although  each  design  concept  shared  similar 
communication  systems  it  was  assumed  that  the  LRS  structural  material  and  placement  of  communication 
devices  would  vary  the  likelihood  of  success  for  establishing  a  communication  linkage  during  recovery. 
This  variation  was  captured  in  the  likelihood  of  communication  success  in  Table  19  of  the  report.  All 
results  from  the  1000  LRS  recoveries  were  data-based  to  a  Microsoft  Excel  spreadsheet  where  they  were 
analyzed  to  evaluate  recovery  performance  of  the  baseline  and  four  alternatives. 

Table  C  -  Recovery  Model  Raw  Data 


Recovery  Model  Raw  Data 


Failed 

Communications 

Not  Detected 
&  No  Host 
Damage 

Not  Detected 
&  Host 
Damaged 

UUV  Detected 
&  No  Host 
Damage 

UUV 

Detected  & 
Host 
Damaged 

LRS 

Success 

Recovery 

Time 

[min] 

Alt-1 

1.8% 

88.7% 

2.0% 

2.0% 

3.5% 

98.0% 

25.63 

Alt-2 

0.5% 

86.6% 

3.4% 

1.1% 

5.8% 

97.4% 

30.05 

Alt-3 

0.8% 

87.7% 

3.3% 

1.1% 

5.7% 

98.6% 

26.95 

Alt-4 

2.9% 

87.2% 

2.7% 

1.1% 

4.6% 

98.5% 

25.47 

Baseline 

1.0% 

81.0% 

3.3% 

2.6% 

8.1% 

96.0% 

37.45 

C.  MAINTAIN  MODEL 


The  Maintain  model  captured  the  performance  of  the  baseline  and  alternatives  to  successfully  stow 
once  recovered  and  successfully  mount  within  the  payload  tube  for  1000  cycles.  The  results  of  the 
simulation  for  each  alternative  are  provided  in  Table  D.  Once  successfully  stowed  the  LRS  is  then 
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able  to  initiate  UUV  maintain  procedures.  The  definition  of  success  for  maintaining  is  dependent 
on  successful:  ISR  data  retrieval,  securing  UUV  in  payload  tube,  LRS  positioning  UUV  for 
securing,  and  communication  between  the  LRS  and  host  platfonn.  The  variable  used  to  simulate 
each  design  concept  can  be  found  in  Table  19  -  Concept  Alternative  Modeling  Parameters.  Unlike 
launch  and  recovery  models,  maintain  procedures  are  internal  to  the  host  platfonn  and  therefore 
are  not  functions  of  varying  sea  conditions. 

Table  D  -  Maintain  Model  Raw  Data 


Maintain  Model  Raw  Data 


Failed 

Positioning 

Failed 

Communication 

Link 

Failed 

UUV 

Securing 

Failed 
ISR  Data 
Download 

Successful 

Maintain 

Stowage 

Time 

[min] 

Alt-1 

1.4% 

1.1% 

0.6% 

0.1% 

96.8% 

12.04 

Alt-2 

0.8% 

0.6% 

0.2% 

0.2% 

98.2% 

11.99 

Alt-3 

1.4% 

1.0% 

0.1% 

0.4% 

97.1% 

12.22 

Alt-4 

1.4% 

1.6% 

0.6% 

0.3% 

96.1% 

10.98 

Baseline 

0.8% 

1.5% 

0.9% 

0.1% 

96.7% 

15.07 
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D.  REPLENISH  MODEL 


The  replenish  model  was  simulated  to  represent  1000  replenish  cycles  and  Table  E  provides  the  raw  data 
to  each  alternative  simulation.  The  parameters  used  for  modeling  are  identified  per  were 
Table  19  -  Concept  Alternative  Modeling  ParametersTable  19  -  Concept  Alternative  Modeling 
Parameters.  The  replenish  model  was  independent  of  all  other  models  (Launch,  Recovery,  and  Maintain) 
and  success  is  defined  by  successfully:  establishing  communication  between  Host/LRS/UUV,  refueling 
UUY,  diagnosing  LRS/UUV  system,  reconfiguring  system  with  software  updates  and  uploading  future 
mission  data.  All  data  was  collected  in  a  Microsoft  Excel  data-base  that  was  analyzed  with  descriptive 
statistics  to  evaluate  replenishment  performance. 


Table  E  -  Replenishment  Model  Raw  Data 


Replenishment  Model  Raw  Data 


Failed 

Commu 

nication 

Link 

Failed  Re- 
Charging 

Failed 

Diagnos 

tics 

Failed 

Reconfigur 

ation 

Failed 

Mission 

Upload 

Successful 

Replenish 

Replenish 

Time 

[hour] 

Alt-1 

1.3% 

1.6% 

1.9% 

1.4% 

0.8% 

93.0% 

45.55 

Alt-2 

0.4% 

2.6% 

1.7% 

0.4% 

0.6% 

94.3% 

45.54 

Alt-3 

1.4% 

2.4% 

1.2% 

1.5% 

1.1% 

92.4% 

45.55 

Alt-4 

1.8% 

3.4% 

1.4% 

1.0% 

1.3% 

91.1% 

43.70 

Baseline 

1.7% 

1.3% 

1.9% 

0.9% 

0.6% 

93.6% 

45.56 
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APPENDEX  E  -  TEST  AND  EVALUATION  STRATEGY 


PART  I  -  INTRODUCTION 

1.1.  Purpose.  The  Test  and  Evaluation  Strategy  (TES)  provides  an  overview  into  testing  at  various 
phased  of  design  and  production  for  the  Launch  and  Recovery  System  (LRS). 

1.2.  Mission  Description.  For  submarine  launched  UUVs  to  be  an  effective  tool  for  undersea 
warfare  persistent-ISR  operations,  a  system  is  required  to  integrate  the  host  submarine  and  the  Large 
Vehicle  Class  UUVs.  This  system  must  provide  launch,  recovery,  replenishment  and  communication 
capabilities  without  adversely  affecting  the  certification  of  the  host  submarine  for  unrestricted  operations. 

1.3.  System  Description.  The  LRS  system  has  8  major  components:  Support  Structure,  Recovery 
Mechanism,  Launch  Mechanism,  UUV  Recharging  Mechanism,  UUV  Stowage  System,  Launch  and 
Recovery  Control  System  Architecture,  Short-Range  RF  Communications,  and  Acoustic  Homing 
Communications.  There  are  5  top  concept  alternatives  developed  which  provide  various  combinations  of 
alternatives  for  the  major  components.  Support  Structure  will  be  either  carbon  steel,  titanium  or 
composite.  The  Recovery  Mechanism  has  4  options:  Swim  to  Cradle,  Electro-Mechanical  Device, 
Articulated  Mechanical  Arm,  or  a  Tethered  Remote  Vehicle.  The  Launch  Mechanism  has  three  options: 
Swim  Away,  Pressurized  Gas  Ejection  or  an  Electro-Mechanical  Device.  The  UUV  re-charging 
Mechanism  supports  three  options,  all  with  the  UUV  in  the  stowed  position:  a  Wet  Cable  Connection,  Dry 
Cable  Connection  or  an  Inductive  Charging  Method.  The  UUV  stowage  system  also  has  three  alternative 
options  in:  Mechanical  Locks,  Sealed/Dry  Compartments  in  the  Payload  Tube  or  Magnetic  Locks.  The 
Launch  and  Recovery  Control  Ann  System  Architecture  has  been  chosen  to  be  a  Portable,  Plug-in  Control 
Hardware/Software.  The  Short-Range  RF  Communications  component  will  utilize  underwater  radio 
waves.  The  Acoustic  Homing  Communications  will  use  an  Acoustic  Homing  Beacon. 

1.3.1.  System  Threat  Assessment.  The  LRS  will  contend  with  threats  in  all  phases  of  use,  from 
accidental  damage  during  the  loading  operations  and/or  transport  to  detection  by  enemy  sonar  and  radars 
leading  to  torpedo  and  missile  attack  as  well  as  risk  of  accident  as  the  UUV  movement  and  operability  is 
affected  by  ocean  currents/tides  and  unwanted  detection  of  acoustic  communication  leading  to 
compromise  of  the  UUV  and  host  submarine  assets.  Threats  during  data  transfer  also  include  active  and 
passive  enemy  detection  capabilities  requiring  a  level  of  encryption  and  security  that  may  further  inhibit 
timely  information  transfer. 

1.3.2.  Program  Background.  From  the  component  matrix,  five  leading  concepts  were  chosen  as 
the  most  likely  concepts  meeting  the  requirements  of  the  LRS.  Since  components  are  in  various  stages  of 
technological  development,  components  will  require  varied  levels  of  developmental  testing  to  ensure  that 
each  concept/prototype  has  adequate  technology,  when  integrated  to  meet  system  requirements. 

1.3.3.  Key  Capabilities.  The  LRS  will  provide  a  launch,  recovery,  storage  and  recharging 
mechanism  for  long  range  ISR  type  UUVs.  Key  Perfonnance  Parameters  (KPPs)  have  been  identified  for 
the  LRS,  which  will  be  used  in  the  testing  phases  to  ensure  the  developed  system  meets  stakeholder  needs. 
These  KPPs  are:  safe  operation,  affordability,  reliability,  communication  success,  flexibility,  launch 
success  and  recovery  success. 

1.3.3. 1.  Key  Interfaces.  The  LRS  has  direct  interfaces  with  the  VIRGINIA  Block  III  host 
submarine  as  well  as  the  ISR  UUV. 

1.3.3.2.  Special  Test  Requirements.  At  this  time,  no  unique  testing  requirements  are  identified  for 
the  LRS. 
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I.3.3.3.  Systems  Engineering  (SE)  Requirements.  The  SE  approach  for  the  LRS  focuses  on 
concept  development  and  exploration  of  alternate  solutions  at  various  early  acquisition  stages.  The 
requirements  definition  phase  does  not  rule  out  technologies  nor  does  it  force  the  solution  to  a  specific 
development  effort.  Once  the  system  and  physical  architecture  were  defined,  component  areas  were 
identified  and  could  initially  be  compared  to  similar  components  with  various  Technology  Readiness 
Levels.  The  beginning  stages  of  design  synthesis  (concept  design)  identified  top  conceptual  alternatives. 
The  options  for  each  alternative  began  to  identify  possible  technologies  to  be  developed  and  tested.  Once 
the  down  select  to  one  concept  design  to  begin  preliminary  design  happens,  component  alternatives  for  the 
concept  will  be  evaluated  and  developmental  testing  will  be  further  defined. 

PART  II  -  TEST  and  EVALUATION  PROGRAM  MANAGEMENT  AND  SCHEDULE 

2.1.  T&E  Management.  The  contractors  developing  the  prototypes  are  responsible  for  the 
majority  of  developmental  testing,  however,  the  government  is  required  to  approve  the  test  procedures  for 
selected  developmental  tests.  The  government  will  conduct  fully  integrated  operational  testing  with  the 
contractor  on  hand  as  a  witness  and  to  troubleshoot  any  problems.  Technology  Readiness  Levels 
determined  by  the  contractor  shall  be  verified  through  the  Office  of  Naval  Research. 

2.2.  T&E  Data  Strategy.  Data  collection  for  LRS  testing  will  include  modeling  and  simulation 
data  recording  successful/safe  launch  and  recovery  operations,  using  enough  modeling  and  simulation 
runs  to  provide  95  percent  confidence  that  the  developed  system  will  meet  its  perfonnance  requirements. 
Weight  data  will  be  taken  by  calibrated  load  cells  to  detennine  overall  system  weight  and  impact  on  host 
ship.  Acoustic  monitoring  devices  will  record  radiated  noise  from  LRS  operations.  Data  transfer  rate  and 
security  will  be  monitored  and  recorded  to  maintain  minimum  data  transfer  rate  levels. 

2.3.  Integrated  Test  Program  Schedule.  Competitive  prototypes  for  the  LRS  are  not  required. 

The  downselect  for  a  single  concept  will  be  based  on  the  cost  and  capability  analysis  of  the  chosen 
alternatives.  Once  the  concept  baseline  has  been  chosen,  detail  design  and  testing  will  commence.  The 
project  is  too  early  in  development  to  discuss  testing  schedules;  however,  certain  tests  have  been 
identified:  bench  tests  on  launch,  recovery  and  stowage  actuators,  bench  tests  on  communications 
devices,  component  weight  measurements  and  integration  testing  for  the  control  architecture  as  well  as 
LRS  functionality  in  a  non  installed  payload  tube.  All  required  SUBSAFE  testing  and  necessary  OQE  will 
also  be  required. 

PART  III  -  TEST  AND  EVALUATION  STRATEGY 

3.1.  T&E  Strategy  Introduction.  At  the  preliminary  design  phase,  the  Test  and  Evaluation 
Strategy  mimics  the  Test  Program  Schedule  -  bench  testing  on  the  component  level  and  integration  testing 
on  the  system  level.  All  components  that  are  identified  as  SUBSAFE  will  have  appropriate  SUBSAFE 
testing  and  documentation  integrated  into  the  test  schedule.  Each  identified  interface  for  the  LRS  will  be 
evaluated  to  ensure  all  requirements  of  the  ICD  are  met. 

3.2.  Evaluation  Framework.  Early  stage  testing  will  emphasize  the  evaluation  of  components  and 
concepts  to  determine  the  best  performers  and  allow  insight  into  possible  combinations  of  components  for 
superior  performance.  Each  component  or  sub-system  will  be  evaluated  for  reliability  and  perfonnance 
values  based  on  the  functions  each  component/sub-system  performs.  The  testing  will  provide  validation 
for  our  component  selection  and  the  concept  modeling  and  simulation  output.  As  the  concepts  mature  and 
a  prototype  is  chosen,  system  integration  testing  is  performed  based  on  the  outlined  mission  scenarios. 

This  testing  measures  concept/prototype  perfonnance  against  required  values. 
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3.3.  Developmental  Evaluation  Approach.  All  selected  component  options  will  be  developed 
and  tested  to  meet  the  requirements  of  the  functions  they  perform.  Component  testing  shall  be  designed  to 
compare  components  performance  and  reliability  on  each  function  to  which  the  component  is  mapped. 

3.3.1.  Developmental  Test  Objectives.  Once  a  concept  is  selected,  developmental  items  will  be 
identified.  Technology  Readiness  Levels  will  be  assessed  and  development  will  be  directly  influenced  by 
LRS  mission  specific  requirements.  To  accelerate  component  development,  testing  will  reflect  LRS 
specific  mission  requirements  instead  of  generic  functional  requirements.  For  example,  the  UUV  stowage 
system  development  will  have  design  and  testing  based  on  the  specific  constraints  of  the  LRS  program 
(VIRGINIA  Block  III  specific  constraints). 

3.3.2.  Modeling  &  Simulation  (M&S).  Early  stage  modeling  and  simulation  was  used  to  select 
concept  alternatives.  The  LRS  is  a  mechanical  system  and  limited,  if  any  modeling  and  simulation  will  be 
required  for  follow  on  testing  once  a  component  baseline  is  selected.  All  components  can  be  mechanically 
or  electrically  tested  in  their  environment  or  simulated  environment. 

3.3.3.  Test  Limitations.  With  a  specific  concept  chosen,  testing  will  be  based  on  each 
component’s  function  within  the  LRS.  Issues  with  future  integration  into  the  LRS  system  will  arise  if  the 
interfaces  between  components  are  not  clearly  defined.  An  emphasis  on  proper  interface  definition  will 
enable  developmental  testing  of  interfaces  and  reduce  integration  issues.  We  do  not  foresee  limitations 
with  developmental  testing. 

3.4.  Operational  Evaluation  Approach.  When  a  leading  concept  is  selected  from  the  top 
alternatives,  a  more  refined  operational  evaluation  (OPEVAL)  will  be  established.  The  main  approach 
will  be  to  satisfy  the  identified  OPSITS  chosen  as  representative  missions  for  the  LRS.  Personnel  will 
require  training  with  the  LRS  to  launch,  recover,  replenish  and  maintain  the  LRS  prior  to  OPEVAL. 

3.4.1.  Mission-Oriented  Approach.  As  the  LRS  is  limited  in  external  interfaces  (host  submarine 
and  UUV),  only  two  phases  of  operational  testing  has  been  identified  at  this  time.  A  LRS  will  be  installed 
into  a  test  payload  tube  with  a  remote  control  station  and  conduct  submerged  launch  and  recovery 
operations  on  the  UUV.  For  the  2nd  phase  of  operational  testing,  the  fully  functioning  LRS  will  be 
installed  on  a  VIRGINIA  Class  Block  III  submarine  and  run  through  full  launch  and  recovery  operations. 
Successful  completion  of  Phase  I  will  give  the  green  light  for  Phase  II.  If  Phase  I  is  unsuccessful, 
redevelopment  of  the  LRS  will  commence.  Phase  II  can  only  begin  upon  successful  completion  of  Phase 
I. 

3.4.2.  Operational  Test  Objectives.  A  full  theater  will  be  developed  to  provide  realistic 
environments  for  the  stated  OPSITS.  The  LRS  will  progress  through  each  OPSIT  being  evaluated  against 
the  identified  KPPs  in  each  OPSIT. 

3.4.3.  M&S.  Early  stage  modeling  and  simulation  was  used  to  select  concept  alternatives.  The 
LRS  is  a  mechanical  system  and  limited,  if  any  modeling  and  simulation  will  be  required  for  follow  on 
testing.  All  components  can  be  mechanically  or  electrically  tested  in  their  environment  or  simulated 
environment. 

3.4.4.  Test  Limitations.  No  operational  test  limitations  are  foreseen  at  this  stage  of  preliminary 
design.  If  a  component  cannot  be  tested  in  its  direct  environment,  a  sufficient  environment  can  be 
provided  to  simulate  the  actual  working  environment. 

3.5.  Future  Test  and  Evaluation.  No  future  testing  has  been  identified.  Developmental  and 
Operational  Tests  will  be  expanded  upon  once  a  single  concept  is  selected  and  interfaces  are  refined  with 
concept  specific  parameters. 
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PART  IV  -  RESOURCE  SUMMARY 

4.1.  Introduction.  Testing  will  take  full  advantage  of  existing  DoD  ranges,  facilities,  and  other 
resources  wherever  practical.  Hydrostatic  testing  of  larger  components  or  prototypes  required  to 
withstand  test  depth  can  be  tested  at  NSWCCD  or  a  test  tank  in  Annapolis,  Md. 

4.1.1.  Test  Articles.  The  first  stage  if  integrated  testing  will  involve  a  VIRGINIA  Class  Block  III 
Payload  Tube  (not  integrated  into  submarine),  a  test  facility  with  sufficient  depth  to  conduct  UUV  launch 
and  recovery  operations,  3  nominally  sized  ISR  UUVs,  and  a  mockup  of  the  LRS  control  station.  Full 
system  integration  testing  will  require  a  dedicated  VIRGINIA  Class  Block  III  submarine  with  an  available 
payload  tube,  a  LRS  fully  outfitted  into  the  host  sub,  3  nominally  sized  ISR  UUV’s,  sufficient  water  depth 
to  conduct  ISR  operations  and  required  support  vehicles  as  well  as  divers  in  the  water  to  observe  launch 
and  recovery  operations. 

4.1.2.  Test  Sites  and  Instrumentation.  No  specific  test  ranges  have  been  identified;  however,  the 
selected  site  will  have  to  provide  an  ideal  radiated  noise  testing  environment  as  well  as  sufficient  depth  to 
conduct  UUV  launch  and  recovery  operations.  Water  clarity  must  be  sufficient  to  allow  video 
documentation  of  launch  and  recovery  operation. 

4.1.3.  Test  Support  Equipment.  Underwater  radiated  noise  equipment  and  testing  personnel  must 
be  available  to  record  noise  levels  associated  with  operation  of  LRS  system.  Equipment  and  personnel 
(divers)  to  support  underwater  video  documentation  of  the  LRS  operation  is  also  required.  Sufficient  time 
recording  devices  and  personnel  are  required  to  record  elapsed  time  of  each  of  the  LRS  phases. 

4.1.4.  Threat  Representation.  The  test  facility  must  also  be  able  to  simulate  various 
environmental  threats  (sea  state,  water  clarity,  currents)  to  the  launch  and  recovery  operations  of  the 
system.  Radiated  noise  testing  will  detennine  system  stealth  to  protect  from  acoustic  threats. 

4.1.5.  Test  Targets  and  Expendables.  The  LRS  will  not  use  any  expendable  test  articles.  The  test 
ready  LRS  will  be  a  fully  functional  system  on  an  operational  VIRGINIA  Class  Block  III  submarine. 
UUVs  used  for  LRS  testing  will  be  actual  mission  capable  UUVs. 

4.1.6.  Operational  Force  Test  Support.  A  VIRGINIA  Block  III  submarine  will  be  required  for  a 
16  week  outfitting  period  and  2  week  testing  period.  DOD  Communication  satellites  with  submarine  an 
UUV  communications  will  be  required  for  the  2  week  testing  period.  An  operational  support  surface  ship 
will  also  be  required  for  the  2  week  testing  period. 

4.1.7.  Simulations,  Models  and  Testbeds.  Early  stage  modeling  and  simulation  was  used  to  select 
concept  alternatives.  The  LRS  is  a  mechanical  system  and  limited,  if  any  modeling  and  simulation  will  be 
required  for  follow  on  testing.  All  components  can  be  mechanically  or  electrically  tested  in  their 
environment  or  simulated  environment. 

4.1.8.  Joint  Mission  Environment.  Operational  testing  of  the  LRS  will  make  use  of  long  range 
ISR  UUVs.  For  some  aspects  of  testing,  dedicated  UUV  mission  planning  support  will  be  required  in  the 
instances  where  a  UUV  is  given  an  updated  recovery  location  from  the  original  uploaded  mission  plan. 

4.1.9.  Special  Requirements.  The  LRS  is  not  scheduled  to  use  any  special  instrumentation  or 
analysis.  The  testing  strategy  makes  use  of  testing  methods  and  instrumentation  that  is  already  developed 
and  proven  by  the  U.S.  Navy. 

4.2.  Test  and  Evaluation  Funding  Summary.  NO  LFT&E  test  are  required  for  the  LRS. 
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APPENDEX  F  -  DECISION  AND  SCORING  TABLES 


The  decision  scoring  tables  below  show  the  weighted  averages  of  the  end  users  priorities  with  respect  to 
system  capabilities.  The  “Maximax”  principle,  picking  the  highest  scoring  value,  was  used  in  selection  of 
the  recommended  alternative.  Where  only  “0”  is  assigned  for  a  particular  category,  either  there  is  no 
rationale  to  differentiate  the  design  characteristic  from  one  alternative  to  another  or  other  categories 
already  encompass  the  infonnation. 


Design  Characteristic 

Weight 

Launch  Speed 

2.3 

Recovery  Speed 

2.3 

Reliability  (Success) 

1.7 

Operational  Depth 

1.7 

Charging  Capacity 

1.3 

Acoustic  Signature  (Detection) 

0.9 

Shock  Resistance 

0.9 

System  Weight 

0.6 

Payload  Space 

0.4 

Data  Transfer  Rate/Clarity 

0.4 
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Table  F-l  Launch  Speed  Scoring  Table 


Launch 

Speed 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

1 

5 

1 

1 

5 

36.8 

ALT-1 

5 

5 

2 

5 

3 

3 

71.3 

ALT-2 

5 

4 

2 

2 

3 

3 

59.8 

ALT-3 

5 

3 

2 

3 

3 

3 

57.5 

ALT-4 

3 

2 

1 

4 

5 

1 

52.9 
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Table  F-2  Recovery  Speed  Scoring  Table 


Recovery 

Speed 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

1 

1 

1 

1 

5 

27.6 

ALT-1 

5 

4 

5 

5 

5 

1 

78.2 

ALT-2 

2 

2 

2 

2 

2 

4 

41.4 

ALT-3 

5 

3 

3 

4 

3 

3 

62.1 

ALT-4 

5 

5 

5 

3 

5 

1 

78.2 
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Table  F-3  Reliability  Success  Scoring  Table 


Reliability 

(Success) 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

1 

0 

5 

1 

5 

25.5 

ALT-1 

3 

5 

0 

3 

4 

2 

44.2 

ALT-2 

5 

2 

0 

2 

2 

4 

32.3 

ALT-3 

3 

3 

0 

4 

3 

3 

37.4 

ALT-4 

3 

4 

0 

1 

5 

1 

39.1 
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Table  F-4  Operational  Depth  Scoring  Table 


Operational 

Depth 

Risk 

Performance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

0 

0 

1 

1 

0 

6.8 

ALT-1 

3 

0 

0 

3 

4 

0 

23.8 

ALT-2 

4 

0 

0 

4 

2 

0 

20.4 

ALT-3 

2 

0 

0 

2 

3 

0 

17 

ALT-4 

5 

0 

0 

5 

5 

0 

34 

200 


Table  F-5  Charging  Capacity 


Charging 

Capacity 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

1 

1 

3 

3 

3 

20.8 

ALT-1 

3 

3 

3 

5 

1 

5 

31.2 

ALT-2 

3 

4 

3 

5 

1 

5 

33.8 

ALT-3 

3 

2 

3 

5 

1 

5 

28.6 

ALT-4 

5 

5 

5 

1 

5 

1 

41.6 
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Table  F-6  Acoustic  Signature  Scoring  Table 


Acoustic 

Signature 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum 

of 

Ranks) 

Baseline 

1 

1 

2 

3 

0 

5 

11.7 

ALT-1 

5 

5 

3 

5 

0 

1 

21.6 

ALT-2 

2 

2 

5 

5 

0 

3 

17.1 

ALT-3 

4 

4 

4 

5 

0 

3 

21.6 

ALT-4 

3 

3 

1 

1 

0 

1 

10.8 
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Table  F-7  Shock  Resistance  Scoring  Table 


Shock 

Resistance 

Risk 

Perfonnance 

(x2) 

Interfaces 

Reliability 

Safety/ 

Usability 

(x2) 

Logistics 

Use 

(Sum  of 
Ranks) 

Baseline 

1 

1 

1 

1 

1 

5 

10.8 

ALT-1 

3 

5 

5 

3 

4 

1 

27 

ALT-2 

4 

2 

3 

4 

2 

3 

19.8 

ALT-3 

2 

4 

3 

2 

3 

3 

21.6 

ALT-4 

5 

3 

5 

5 

5 

1 

28.8 
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